Four Ways a First MVP Goes Wrong

Notes from building first products with founders who have never built one before — including the mistakes we made ourselves.

A quick definition first, because the term gets used loosely. An MVP — minimum viable product — is the smallest version of your product that can go in front of real users and tell you something true. Not a demo, not a clickable prototype. A working thing, deliberately small.

We build these with founders going from zero to one. We also work with teams past that point: companies that have already proven people want the product and have raised money to grow it. I've launched my own products, and I spend a fair amount of time talking to VC funds about what they check before they write a cheque.

This is written for founders who don't come from a technical background and are commissioning development for the first time. The four mistakes below are the ones I see most often. None of them are about having a bad idea. Every one is a gap between two pieces of work that were each done reasonably well on their own.

1. Trying to validate every idea at once

The most common failure isn't a weak idea. It's the attempt to test all of them simultaneously.

You have a long-term vision — a full picture of what the product becomes in three years. Then you try to build that picture in version one. Everything from the roadmap ends up in the first release, and nothing gets tested properly, because a product stuffed with features tells you nothing about which feature people actually came for.

Reid Hoffman's version of this is well known: if the first release doesn't slightly embarrass you, you shipped it too late.

What works instead is a fast loop. Sketch quickly, build, ship, watch what happens, change it. Teams that work this way don't get stuck in permanent development — the state where you spend a year building and still don't know whether the problem you're solving exists. And that's the real uncertainty. You don't know if the problem is there. Even if it is, you don't know which solution fits it best. Neither question can be answered by building more.

So fall in love with the problem, not with your solution to it. That's also the difference between a business you can run for years and a project you burn out on the first time a release doesn't land.

One note if you're building a mobile app. App Store review is its own timeline, controlled by Apple and routinely longer than founders plan for. Treat submission as a milestone with its own schedule, not the last box to tick before launch.

The cost of drowning in development isn't only the calendar. It pushes back everything downstream: how you'll reach users, what you'll say to them, what your first month of marketing looks like. If you're selling to consumers and still haven't decided what you're actually selling, you end up sending several different messages at once and none of them land. Ship first, then look at what happened.

2. Getting the design-to-development split wrong

This one is awkward for a design studio to write about, so read it as a budgeting problem rather than a pitch.

If you're bootstrapped — spending your own money rather than an investor's — the imbalance tends to go one of two ways.

You spend heavily on design and run out of money for engineering. You end up with a beautiful set of screens, then hire developers who don't have the experience to build them. What gets built resembles the designs from a distance. The design money is gone; you paid for a picture.

This is the harder one to see coming if you're non-technical, because design is the part you can evaluate yourself. Screens look good or they don't. Code doesn't work that way. Three things protect you, and all three happen before anyone is hired:

You skip product design entirely. This is expensive in a different way. If you're entering a market that already has competitors, the experience of using your product is often the only place you can win — you're not going to out-build an established company on features in your first year. Cutting the one thing that would set you apart isn't a saving.

There's no correct ratio. It depends on who you're selling to and where the money comes from. A tool sold to businesses, one deal at a time, in conversations you're personally in, tolerates a rougher interface than a consumer app that has to convert a stranger who arrived from an ad and owes you nothing. Bootstrapped and funded teams shouldn't be spending the same way.

The point is to decide the split deliberately, before you commission either side — not to discover it when one of the two runs out of budget.

3. Building before you understand how you'll reach users

Not knowing your go-to-market — the plan for how users find you and why they stay — usually gets filed as a marketing gap. It isn't. It's a design gap, and it shows up in the product long before it shows up in a campaign.

If you don't know how users will arrive, you can't design what happens when they do. Concretely, these questions stay open:

Say you acquire a user through paid ads. What converts them inside the product — a subscription prompt, a registration wall, a specific first action? That path has to be designed as one continuous thing, from the ad to the moment they pay. When it isn't, you get a gap: traffic arrives and nothing catches it. You've paid for the click and lost the user in the first thirty seconds.

The same applies to where the product is going. You don't need a certain roadmap, but you need a rough one — enough for the people building it to lay foundations that support what comes next.

Two things carry that weight. The first is the technical architecture: how the code is organised underneath. The second is the design system: the reusable set of buttons, forms, layouts and rules that new screens get assembled from, instead of being drawn one at a time. Both are decided at the start, and both are invisible to you as a client. They're the reason one team can add a feature in a week and another needs two months.

The pattern I see repeatedly: a team designs and builds, then decides six months later to move in a different direction, and redoes everything from zero. The money already spent gets written off. It's avoidable. Extending a product is far cheaper than rebuilding it — but whether extension is even possible was decided before the first screen was drawn.

4. Shipping the product without the packaging

The product isn't the whole deliverable.

It has to be consistent with everything around it: your social accounts, the deck you send investors, your App Store screenshots, the way you describe yourself in a sales conversation. Founders either forget this or weight it wrong. The most common version is a large investment in a website that most of your users will never see.

The fix is prioritisation. List every place a person could encounter you — an ad, a friend's recommendation, a search result, an app store listing, a cold email — and put them in the order a real user actually hits them. Then build in that order. Done properly, this is what turns a pile of separate assets into something that reads as one company rather than four freelancers.

What investors are actually checking

If you plan to raise, one question sits above the others: is this scalable? Meaning, can this grow much faster than the cost of running it?

In practice that means one of two things. Either the problem is large enough that a great many people have it, and you grow by user count. Or the problem itself grows — customers need more from you over time, and the product expands with them.

Which is why the framing matters more than it sounds. Start from the problem, not from the idea. An idea is a solution you've become attached to. A problem is something you can size, measure, and defend in a room full of people who have heard the same pitch shape many times this month.

Decide these before anyone starts building

Six things. None of them require a technical background, and all of them are cheap to change now and expensive to change later.

Move fast, but don't rush

These two aren't in tension. Moving fast means shipping before you're comfortable and learning from real users. Rushing means skipping the decisions above, which is what makes rework necessary later.

Rework costs time and money, and in a startup you have a limited supply of both.

If you want help with any part of this — problem validation and research, MVP scope, feature and stack decisions, or how the product is packaged and presented — that's the work we do. Get in touch.