Architecture Decisions That Speed Up MVPs

engineering architecture mvp

When you’re building alone, every architectural decision either accelerates you or bogs you down. After 9 years of engineering and several side projects, here are the technical choices I keep making - and why.

Pick a Boring Stack

The best stack for an MVP is the one you already know. Novelty is the enemy of speed. For me that’s TypeScript end-to-end, but the principle applies regardless of your preferred language.

Monorepo Until It Hurts

Splitting into microservices before you have product-market fit is premature optimization. A monorepo with clear module boundaries gives you the speed of a monolith with the option to split later.

Ship on Day One

Deploy your empty project to production on day one. Not day thirty. This means:

  • CI/CD from commit #1 - even if it’s just “push to main = deploy”
  • Real domain, real SSL - no localhost demos
  • Feature flags over branches - ship to production, gate behind flags

Database Choices

For MVPs, I default to PostgreSQL with an ORM. NoSQL has its place, but relational databases give you:

  • Schema enforcement (catches bugs early)
  • Powerful querying (you will need ad-hoc queries)
  • Battle-tested tooling and hosting options

The Auth Question

Don’t build auth. Use a managed service. The time you spend building login, registration, password reset, and session management is time not spent on your core product.

What I Skip

  • Custom design systems (use Tailwind + shadcn/ui)
  • Complex state management (start with URL state + server state)
  • Comprehensive test coverage (test critical paths, skip the rest until PMF)
  • Performance optimization (ship, measure, then optimize)

The goal of an MVP is to learn, not to impress other engineers. Optimize for speed of iteration, not architectural elegance.