Five decisions that make or break an MVP

The MVP trap

Every MVP we inherit has the same story: it was built fast, it found traction faster, and then the team spent the next year paying interest on decisions nobody wrote down.

Moving fast isn't the problem. Moving fast without thinking through a small number of decisions is. Across the projects we've rescued, the same five calls come up every time — and getting them right costs almost nothing, while getting them wrong costs months.

1. Pick a boring database

We know you've read the post about event sourcing and CQRS. Don't do it. Pick Postgres. Run it managed. Put indexes on the columns you query by. You can add complexity later, once the shape of the data is obvious — and by then you'll actually know what shape that is.

The teams that get stuck aren't the ones who chose Postgres. They're the ones who chose something interesting.

2. Write the auth boundary once

The single most common rewrite we've been hired to do is "our auth story got away from us." It starts with a cookie, grows a session token, sprouts an API key system, and six months later you have four different ways to be logged in and none of them agree on what a user is.

Pick one identity library. Pick one session primitive. Put every route through the same guard. Treat it like the load-bearing wall it is.

3. Decide what's synchronous

Everything that touches a user request should be fast and in-process. Everything that doesn't — emails, webhooks, analytics, exports — goes through a queue. That's the whole decision.

Teams that skip this one end up with a single path where every request waits for Stripe to respond, and wonder why P99 latency looks like an earthquake chart.

4. Write the README on day one

We're not kidding. Half a page: how to run it, how to deploy it, what the three or four moving pieces are. Update it every time someone says "oh yeah we also have that Cloud Function for…"

Every rescue engagement we take on starts with us reverse-engineering the README that should have been there from the beginning. It's the cheapest investment in the entire project.

5. Ship to production in week one

Not a staging environment. Not a feature-flagged preview. Production, with a real domain, real HTTPS, real monitoring. Even if the only thing it does is return "hello world."

Every piece of infrastructure you're going to fight with — certs, DNS, secrets, CI/CD, rollbacks — you will fight with. The only question is whether you fight with them in week one, or in week ten when you're also trying to ship the product.

A short conclusion

An MVP is not a prototype. It's a production system with less in it. Treating it like a prototype is how you end up with the rewrite we get paid to do six months later. Treating it like a real piece of software — with five small, boring, on-day-one decisions — is how you end up with a product.