The Solo Dev Build System: How One Person Ships Like a Team

People ask how one person runs this many projects at once. The honest answer is unglamorous: almost nothing is built from scratch anymore. There is a system, and at this point the system is the real product. Every individual project is just the system pointed at a new idea.

It did not start as a system. It started as me doing the same handful of things over and over across project after project, eventually noticing the pattern, and then writing the pattern down so I would never have to rediscover it. That is the whole origin. A system is just a pattern you respected enough to record.

Here is the shape of it, in order.

It starts with a name and a domain, and then one specific question: what does the homepage promise, in a single sentence. If I cannot write that sentence cleanly, the project is not ready to build yet. The sentence is the test. A project that cannot be said in a line is a project that has not been thought through.

Then the framework, chosen by the job and not by habit. Content and SEO sites get Astro, because for static, fast-loading pages that is the right tool. Applications with real authentication and dashboards get SvelteKit. Simple tools and games get plain HTML and JavaScript, because not everything needs a framework and pretending it does is just future maintenance you signed up for with no reason. The decision is made once, deliberately, and then it is not reopened every time.

Then the same day-one checklist, applied on every single project before any content goes in. Canonical tags. A sitemap. Robots rules. Security headers. Structured data. The redirect from the www version to the bare domain. HTTPS forced on. None of that is interesting. All of it is the difference between a site search can trust and a site it cannot, and doing it on day one costs an hour. Retrofitting it later costs a week and a ranking dip.

Legal pages early, not as a launch-day scramble. SEO architecture before the content, not bolted on after. A basic but genuinely working version shipped, not a perfect version delayed. Then watch for any real signal at all: a signup, a use, an actual inquiry from an actual stranger.

And then, only then, decide what deserves to be automated.

That last step is the one most people skip, and it is the most important one in the whole system. The instinct, especially for a builder, is to automate everything and build the full machine on day one. Most of the time that is wasted work, because you are automating a process before you know whether anyone wants the output. A concrete example: for a one-off transaction, the right move was not to build a whole intake-and-fulfillment system with forms and a workflow and a dashboard. It was to send a single Stripe invoice by hand. Do the manual thing until the volume genuinely justifies the machine. Overbuilding before validation is just a slower, more expensive way to be wrong.

AI coding agents fit into this as the execution layer, and only the execution layer. The system decides what gets built and in what order. The agent does the typing. My job is the part that does not delegate and never will: the product decisions, the architecture, the constraints I hand the agent, and the verification of what comes back. I describe precisely, the agent executes, I check the result against reality. That division of labor is the whole job.

Here is why the system matters more than any single project in the portfolio. Most projects will not win. That is not pessimism, it is just the math of trying things, and it is the entire reason you want many shots rather than one. But a system means every shot costs less than the one before it. The first SaaS is brutal, because you are learning billing and metering and abuse handling for the first time. The fifth project on the same stack starts from a running start, because all of that is solved and recorded. The compounding is not inside any one project. It is in the machine that makes the next one cheap.

So shipping like a team as a single person is not about working like ten people. That does not scale and it does not last. It is about building a system disciplined enough that you never have to solve a solved problem twice. Do that, and one person with the right machine can cover a genuinely surprising amount of ground.