How to Build an MVP That Won't Need a Rewrite in a Year

I've heard some version of this sentence from almost every founder I've worked with: "We just need something quick. We'll rebuild it properly once we raise."

The rebuild rarely happens on schedule. Once customers are using the product, there's always a more urgent feature. The "temporary" MVP becomes the foundation for the next three years. That's fine if you planned for it, and painful if you didn't.

The good news is that building an MVP you won't regret isn't much slower than building one you will. It mostly comes down to knowing which decisions matter early.

Decide now, or decide later?

The left column is hard to change once you have users and data. The right column is easy to add later, when you know you need it.

Why the data model matters most

If I could give founders one piece of advice, it would be this: spend a day on your data model before you write features.

Screens will change many times. How you represent your customers, accounts, orders or whatever your core records are is much harder to change once real data exists. A classic example is assuming each user belongs to exactly one company. That holds until your first enterprise customer wants a consultant to access three of their subsidiaries, and then the change touches every table.

Screens are cheap to change. Data is expensive to change. Design accordingly.

A realistic 12-week plan

Weeks 1 to 2: foundations

Agree on the single problem the MVP solves and how you'll measure success. Set up the code repository, automated deployments, sign-in and a staging environment. It feels slow, and it pays you back every week after.

Weeks 3 to 6: the core workflow

Build the one workflow that delivers the value, end to end, and nothing else. If your product helps contractors send quotes, a contractor should be able to create and send a quote by week six, even if it looks plain.

Weeks 7 to 9: real users

Put the product in front of five to ten real users and watch them use it, live if you can. You'll learn more in these three weeks than in the six before them.

Weeks 10 to 12: fix, harden, launch

Fix whatever confused people. Add error tracking, backups you've restored at least once, and basic rate limiting. Then open it up to a wider group.

Shortcuts that are fine

• Using a managed hosting platform instead of running your own servers
• One well-structured application instead of microservices (it will scale further than most startups ever need)
• Off-the-shelf payments, email, sign-in and analytics instead of building your own
• Doing admin tasks by hand instead of building an admin panel
• A simple, consistent UI component library instead of a custom design

Shortcuts that aren't

• No automated deployments. Manual releases get scarier every week, and then they stop happening.
• Customer data in the wrong place. Moving it later to satisfy a large customer's compliance team is slow and stressful. If you plan to sell to enterprises in Canada or the US, ask early where they need their data stored.
• No tests around money. You can skip a lot of tests in an MVP, but not around billing, payments or anything that charges a customer.

Before you start building

• We can describe the problem in one sentence
• We know the one metric that proves the MVP works
• We've sketched the core data model and tested it against real scenarios
• Deployments will be automated from week one
• We know where customer data will be stored
• We have five to ten users lined up to try it

If you're about to start an MVP, or you're six months in and starting to feel the cracks, I'm happy to look at your plan or your code. Book a free call and we'll work out what to protect now and what can wait.