Micro-SaaS Architecture for Solo Founders

Most architecture advice is written for teams. It optimizes for coordination: clear boundaries, ownership, testability across people. A solo founder has none of those constraints and a different one that matters more, which is that every hour spent on infrastructure is an hour not spent on the product.

That single constraint changes which tradeoffs are worth making.

The boring stack is the correct stack

One server process. Postgres. A background job runner that uses the same database. A single deployment target. One domain, one CDN, one error tracker, one analytics tool.

Every microservice, every separate queue, every extra datastore is a second thing that can fail while the founder is asleep. At the micro-SaaS scale, the operational overhead of distributed systems is pure cost with no benefit. There is no team to parallelize across.

The boring stack loses on paper in every benchmark. It wins in practice because the founder can still ship features on it at month eighteen.

Buy the commodities, build the product

A solo founder should not be writing:

• Authentication. Clerk, Supabase Auth, or equivalents. Custom auth is a tax that compounds.
• Billing. Stripe for web, RevenueCat for mobile. Roll-your-own billing is a liability.
• Transactional email. Postmark, Resend, or equivalents. SMTP is someone else's problem.
• Error tracking. Sentry or equivalent. Free tiers are sufficient for years.
• Analytics. PostHog, Mixpanel, or equivalents. A custom events table is not a differentiator.

Each of these has a free or low-cost tier that covers the first several thousand users. The time saved is not marginal. It is the difference between shipping a feature every two weeks and shipping one every two months.

Overinvest in the parts that are hard to change later

The shortcuts that are safe to take are in UI, admin surfaces, reporting, and internal tooling. The shortcuts that are never safe to take are in data modeling, webhook handling, and state transitions that touch money.

The data model decides what the product can be. A confused schema calcifies into confused product logic. Spending an extra week on domain modeling before any real code is written is almost always worth it.

Webhook handlers decide whether your billing is correct. They need to be idempotent, logged, and replayable from day one. Fixing this later means cleaning up corrupted subscription state across a paying customer base.

State machines that touch money, entitlements, or account status need to be explicit. Enumerate the states. Name the transitions. Log every change. This is the code that has to be right even when everything else is held together with tape.

Custom infrastructure is usually avoidance

Solo founders who are uncomfortable with product work sometimes build an extraordinary amount of custom infrastructure. A homegrown job queue. A custom metrics pipeline. A self-hosted auth system.

Every one of these is more fun than pricing, support, and onboarding. None of them move the business. If you notice yourself choosing to rewrite a part of the infrastructure that already works, check whether the real problem is that the product roadmap has a question you are avoiding.

The exit ramp matters more than the architecture

The goal of a solo-founder architecture is not to stay solo. It is to let you hire an engineer in a year without rewriting everything.

That means a few decisions you make now pay back later:

• A domain model that can be explained in one conversation
• Commit history and migration history that tells a linear story
• Infrastructure that does not require tribal knowledge to deploy
• Tests that cover the parts of the code that handle money and user data, even if nothing else is tested

None of this slows the product down in the first six months. All of it compounds when the first hire shows up.

The single question

Before adopting any new piece of infrastructure, the test is whether it meaningfully reduces the number of hours you spend on non-product work this month. If it does not, it is a distraction, and distractions are the only thing that can kill a one-person business.