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 gets built from scratch anymore. There is a system under all of it, and at this point the system is the real product. Every individual project is 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, project after project, until I finally noticed the pattern and wrote it 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 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 you cannot say in one line is a project you have not finished thinking about.

Then the framework, picked by the job. Content and SEO sites get Astro, because for static, fast-loading pages it is the right tool and I am not going to argue with it. Apps with real auth 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 yourself up for for no reason. The decision gets made once, on purpose, and then I leave it alone instead of relitigating it every week.

Then the same day-one checklist, run on every 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 it is interesting. Skipping it is the difference between a site search trusts and a site it shrugs at, and doing it on day one costs an hour. Retrofitting it later costs a week and a ranking dip you get to watch happen in real time.

Legal pages early, before they become a launch-day scramble. SEO architecture before the content. Ship a basic version that genuinely works, and resist the urge to polish a perfect one nobody has seen yet. 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 thing. The instinct, especially if you like to build, is to automate everything and stand up the full machine on day one. Most of the time that is wasted work, because you are automating a process before you know whether anybody wants the output. Here is a concrete one. For a single one-off transaction, the right move was one Stripe invoice, sent by hand, in about four minutes. The full intake-and-fulfillment system with forms and a workflow and a dashboard could wait until there was a second transaction, which there often is not. Do the manual version until the volume actually earns the machine. Overbuilding before validation is a slower, more expensive way to be wrong.

AI coding agents sit in here as the execution layer and nothing past it. The system decides what gets built and in what order. The agent does the typing. My job is the part that never delegates: the product calls, the architecture, the constraints I hand the agent, and checking what comes back against reality. I describe precisely, the agent executes, I verify against the live thing. That division of labor is the entire job.

Here is why the system matters more than any single project in the portfolio. Most projects will not win. That is the math of taking a lot of swings, and it is the entire reason you want many swings instead of one big one. A system means every swing costs less than the last. The first SaaS is brutal, because you are learning billing and metering and abuse handling for the first time with your own money on the line. The fifth project on the same stack starts halfway down the field, because all of that is solved and written down already. The compounding lives in the machine that makes the next project cheap. No single project holds it.

So here is what shipping like a team as one person actually means. A system disciplined enough that you never solve a solved problem twice. Working like ten people does not scale and burns out fast, so I do not try. I build the machine instead, and one person with the right machine covers a genuinely surprising amount of ground.