Building Solo
独立开发One person building products with AI: shipping, security, budgets, costs, and a product process that is no longer linear.
Filter and search this topic in all posts →Some tasks only need to be done once, and signing up for a subscription, installing software and hunting down tutorials can take more effort than the task itself, so I want to try letting people who need something done just hand the task to me.
AI helped me publish 133 posts on RedNote, and the median post got just 112 views; my three most-viewed posts drew over 10,000 views combined and brought in exactly 1 follower.
I turned the job screening, research, and application prep I kept doing while trying to move into AI PM this year into an open-source Agent Skill: Roleward Job Hunting.
The original score of a piece I loved was too hard, and the simplified versions online didn’t fit, so I built an open-source Agent Skill, Score Simplifier, that has AI change only the parts I can’t play and keep as much of what I love as possible.
This day was a video on RedNote.
This day was a video on RedNote.
As a non-technical builder, I don’t plan to learn all of Git. I’ve drawn a boundary of six things for myself: understanding the shared baseline, which version a task is based on, which kind of “done” it is, branches, dependencies, and when to take a decision back.
I now work with a small “team” of ChatGPT, Claude, Codex, Claude Design and Claude Code, but I’m the only human. Using several AIs is easy; getting them to collaborate like a team is much harder.
Indie development isn’t about thinking everything through first, but about telling apart what must be settled now from what can be settled while building: the harder to change and the higher the risk, the earlier to decide; the more it needs a real product to judge, the later.
Building products alone with AI, I’ve found the process has changed from a relay of “requirements → design → development → testing” into going forward loop by loop: build it, see how it works, go back and fill in requirements and design.
Controlling AI costs isn’t just shortening prompts or switching to a cheaper model. I break it into three things: which money shouldn’t be spent at all, how to bound the money that must be spent, and whether the results are still worth using once you’ve saved.
Only while testing the AI job-search product I built did I realize that one full cycle of use could cost several dollars: one button on the page can hide a whole chain of paid calls, and failures and retries cost money too.
Indie development costs are scattered across subscriptions, APIs, cloud services and auto-renewals, so I’ve set myself a fixed routine: once a month, review work expenses — where the money went, what it got me, and how to adjust next month.
Once I started building products myself, I had to pay for everything myself. What I care about more isn’t saving money, but which money is worth spending, and which only makes the product and my way of working more expensive.
With coding agents, the documents in a repo are no longer just records for later; they directly decide how the agent understands the product, how it changes the code, and which way it guesses when something is ambiguous.
After leaving a company to build products on my own, the invisible security protection disappeared, and I have to be my own IT and security team. The most common risk for an indie product usually isn’t a sophisticated attack, but a basic mistake that gets amplified fast.
Almost three months into indie development, with two products shipped and a batch of long posts written, it feels like walking across an empty wilderness: everyone says build in public, but for many people the public is empty.
By D17 I’ve shipped two products and I’m building workflows and scaffolding, yet I keep swinging between “hang on a bit longer” and “cut my losses,” and when results disappoint I can’t find the reason.
For my first indie product I picked a niche market I know: a piano practice tool. I know the setting and the user profile is clear, but the group is small and leaves little room for error.
Launching my first indie product, most of my mistakes came from assuming: assuming my needs were everyone’s needs, that launch was the finish line, and that promotion could wait until “after it’s built.”