Solo Builder

Quick Navigation Start with the long read: 9 sections in the body above. 17 archived notes this month, filed under 7 themes: Daily Notes and Everything Else · 6 AI and Agent Systems · 4 Self-Knowledge and Psychology · 2 Content, Craft and Recording · 2 Business, Investing and Career · 1 Travel, Places and Cities · 1 Reading, Ideas and History · 1 For most of July I was in Shenzhen, and I also stopped briefly for a few days in other cities in Guangdong. ...

I build products on my own, and I want a design system that helps me maintain their UI and frontend over time. Finishing a page is only the beginning: features get added, styles change, and another platform may need support. When I return to a project, I want to build on the design already there and understand what a change will affect. That calls for a method I can maintain myself. When I want to change a color, I need to know where to edit it. When I want a different layout, I need somewhere to compare options. When I hand implementation to AI, it needs to find the existing components. I also want the interface to feel more thoughtfully designed, while starting with free tools wherever possible. File organization, tool choices, and visual judgment are connected problems. ...

At the beginning of 2026, my GitHub contribution graph stayed nearly blank for several weeks. A few months later, the same graph showed hundreds of contributions in a single week. In July, this blog published 55 articles in Chinese , while GitHub’s contribution calendar recorded 733 contributions. Those numbers prove neither quality nor user value, much less a business result. GitHub also makes clear that contributions may include qualifying commits, pull requests, issues, reviews, and other activity; the number cannot simply be relabeled as a commit count. GitHub’s profile contributions reference ...

At dusk, I sat on the rooftop of Youli Café and raised my coffee cup toward the twin pagodas of Kaiyuan Temple. The camera recognized the distant towers and ignored the hand in front of it. Cup and fingers dissolved into a red blur; across the old city, the pagodas held their edges. ...

This is a thought experiment-style simulated interview. The respondents are composed of organizational psychology and organizational economics perspectives, and do not represent any real individuals’ original statements. In my June 2026 monthly review, I wrote: Incentive structures colonize personality. At that time, I studied several founders and observed myself. An organization initially selects a particular narrative, user model, and revenue framework primarily to launch a business. Years later, that structure reverses to filter what members can see, what they are willing to acknowledge, and which behaviors persist. ...

This is the sixth essay in Reckoning with Reality. The previous essay separated fast feedback from slow results. This one turns to a question that technological progress makes easy to neglect: when an old bottleneck disappears, where does the new one appear? Whenever a new tool arrives, people first imagine what it will eliminate. AI makes writing faster, code cheaper, translation nearly instantaneous, and video production possible without a full team. Work that once took days can now be completed in minutes. ...

This is the fifth essay in Reckoning with Reality. The previous essay asked what kind of action can produce evidence. This one examines the speed at which evidence arrives—and how speed quietly changes our goals. A friend told me that content and retail have one enormous advantage: fast feedback. Change the opening today and the view count responds within hours. Adjust the price or the page and clicks or sales may change at once. Compared with spending months building a product in private, only to receive a faint response at launch, this rhythm does make it easier to preserve morale. ...

This is the fourth essay in Reckoning with Reality. The previous essay examined how intelligent people use competence to escape. This one asks the next question: once we leave the study, what kind of action actually brings us closer to the facts? “Think less, do more” may be one of the hardest pieces of advice to dispute today. It sounds brave and direct, and it often works. Many people are stuck not because they lack ability, but because they never quite put their work into someone else’s hands. ...

This is the third essay in Reckoning with Reality. The previous essay examined the limits of profit. This one turns to a more personal question: why can greater ability sometimes make it harder to reach the facts? I used to think that avoiding something must look like scrolling on a phone, procrastinating, or doing nothing. Later I learned that the hardest form of avoidance to recognize is often remarkably diligent. It comes with thorough documentation, elegant architecture, an unbroken commit history, and late nights at work. ...

This is the second essay in Reckoning with Reality. The introduction began with a dinner-table argument. This essay asks only one question: what exactly does profit record on its scorecard? “If a business makes a lot of money,” my friend said, “that means it creates value.” My first impulse was to argue. Then I realized that calling him wrong was easy. Explaining precisely where he was right, and where he went too far, was much harder. ...

This is the introduction to Reckoning with Reality, a seven-part collection of audits on profit, action, technology, and choice. A few days ago, over dinner with a friend, we began talking about what to do next. “The essence of entrepreneurship is making money,” he said. “If a business makes a lot of money, that means it creates value. If it keeps losing money, it is wasting everyone’s time and capital.” ...

Why Does Getting Better at This Make Me More Tired? Let me start with a strange thing I banged my head against for a long time before I understood it. When I first started using Claude Code, the productivity gain was visible to the naked eye: an afternoon’s work covered what used to take two days. Once I got fluent, the gains kept coming — but so did the exhaustion at the end of each day. Because I was doing the same thing all day long: watch it finish, judge whether it’s right, think about what to say next, hit enter again. ...

Last winter I ran a very ugly set of numbers. I’d spent an entire afternoon in a café, writing code and shooting footage in between — about forty minutes of material across phone and screen recording. I started editing that evening and exported at 1:30 in the morning. The finished cut was fifty-eight seconds. Forty minutes of footage. Six hours of editing. Fifty-eight seconds of output. And the numbers on it were mediocre. ...

Same product, different name, different score There’s something I’ve been watching for a long time without finding the right place to write it down. In the same product community, you’ll regularly see two small tools with nearly identical features. One launches and sinks without a trace; the other gets shared repeatedly and draws serious questions. Look at both product pages: similar craftsmanship, similar pricing, landing pages built from the same template, even. The real difference sits in the small line under the maker’s name — “maintainer of such-and-such project,” “has written about xx for three years.” ...

I wasted years on this one sentence “If the product is good enough, people will come.” I believed that line for years. It fits the engineer’s worldview: code is verifiable, performance is measurable, and there’s an objective difference between good and bad. If the difference is objective, then the good thing winning is just a matter of time — the market is efficient, it just needs a while. That was my logic through my open-source years. Write the project well, keep test coverage high, take the docs seriously, and then wait. Wait for stars, wait for issues, wait for someone to mention it in a blog post somewhere. Sometimes the wait paid off. More often it didn’t. And every time it didn’t, my first reaction was the same one: the thing isn’t good enough yet, go back and keep improving it. ...

One morning, and three things that shouldn’t exist One morning I got up, made coffee, opened my laptop, and found the agents I’d left running overnight all parked at “done”: one had added full multilingual support to a small tool of mine — Chinese, English, Japanese copy, an i18n layer extracted; one had built reading-progress analytics for my blog; one had refactored a CLI I wrote six months ago into a plugin architecture. The code was clean. The tests were green. ...

The fifteenth tool list changed the question Over six months, I read roughly twenty or thirty “AI-era super individual” tool lists. Around the fifteenth, the pattern became hard to ignore: the lists differed far less than the competitive advantage each one promised. I use most of the tools they recommend. The problem was not that the recommendations were bad. It was that ten thousand builders could install the same stack in the same week. Their absolute capacity might rise, while the distance between them barely moved. ...

Suppose you had to place a bet today on one direction in AI agents. What is the first question you should ask? Most people ask whether the thing can be built. By mid-2026, that is often the least interesting part. The colder question is: why has nobody made this opportunity routine yet? The answer is a useful filter. If nobody has solved it because everyone just noticed it, competition is probably coming. If nobody has solved it because the work is dirty, slow, and carries consequence, there may be something defensible—or there may be no market. The rest of the article is how I try to separate the two. ...

How many agents can one person afford to keep running? The wrong way to answer is to count agents. An “agent” might classify one paragraph, search for twenty minutes, or refactor a repository through eighty tool calls. The useful unit is not the agent. It is the successful task, with its input tokens, output tokens, tool charges, retries, and human cleanup attached. That distinction changed how I think about two related but different choices: low-cost hosted model APIs and open-weight models that can be self-hosted. Falling API prices matter, but “90% cheaper” is meaningful only when three things are visible: ...

“Software is eating the world.” — Marc Andreessen, 2011 “Now AI is eating software—and the question for the rest of us is: what’s left for one human, alone, in front of a screen?” — me, asking myself one night in 2026. Prologue: How Big Does One Person Need to Be? In February 2026, I ran my first complete overnight agent. I set a prompt, dropped it into Claude Code in a loop, and went to sleep. At 7 a.m. the next morning, what I saw on the screen was: 6 commits, 4 PRs, 3 auto-rolled-back failures, and a research brief I hadn’t even read myself. ...

Independent development creates a seductive illusion: once the stack is chosen, the product is halfway built. I used to make long lists—frontend framework, database, authentication, payments, email, analytics, monitoring. The more complete the list looked, the safer I felt. But that safety came from the feeling of construction, not from evidence that anyone needed the thing. My rule is simpler now: the scarce resource for an independent developer is not code. It is the ability to place limited attention on the right problem. A stack should help you move cheaply, learn quickly, and reverse a decision while the evidence is still thin. ...