Why does a V1 end up holding the company back?

Your V1 got you here. It did its job: customers, revenue, a team. But it was built to prove something, not to carry a business.

The unsettling part is that nothing breaks. The product runs, customers pay, and yet every decision takes a little longer than the last. Nobody can say when it tipped, because it never tipped: it drifted.

What is a V1 actually for?

A V1 has one job: get the cheapest possible proof that a problem is worth money. Anything that pulls it away from that proof is wasted time. You choose fast, you freeze assumptions, you take shortcuts, and that is the right call. A shortcut that saves you three months on a wrong assumption saved you three months.

Those shortcuts have very concrete names. A single type of user, because at the start there is only one job to serve. The price hard-coded, because there is only one offer. Each customer’s data stored next to everyone else’s, because there are only three of them and you know them by first name. None of this is a mistake. These were bets on speed, and they paid off.

Why does what worked end up blocking you?

Because the proof is in, and the goal changed without anyone saying it out loud. It’s no longer about testing a hypothesis: it’s about carrying paying customers. And a shortcut doesn’t behave the same way in those two worlds.

In a V1, a shortcut is a straight line. In a growing product, it’s a dependency: every new customer sits on top of it, every feature leans on it. A second line of business arrives and you’d need a second type of user, except the first one is assumed everywhere. A second offer arrives, and the price is hard-coded in every place it had to be displayed. The first serious customer asks who can see what, and the answer never had to be written down.

None of this sets off an alarm. That’s exactly the problem: the curve doesn’t break, it flattens. And because the product works, nobody dares to stop and consolidate.

How do you know you’ve gone from “it holds” to “it’s holding us back”?

Not from the code. You know from the calendar and from sales, two places you already look at. These are the signals we find in almost every audit, and what they really cost:

• Every new feature takes longer than the last. “A feature that took 2 days six months ago now takes 10.” The dates you promise customers slip.

• Every fix brings up two more problems. “Every deployment was a source of dread.” Days go to repairs, not to new work.

• It slows down as customers arrive. “Customers were starting to complain about slowness.” Subscriptions stop without a stated reason.

• Only one person knows where things are. “Nobody dares touch the code for fear of breaking everything.” Your deadlines depend on one person’s calendar.

• Large accounts ask questions you can’t answer. “Auditors will go through the code.” Contracts wait, then go elsewhere.

A single signal means nothing: every living product has one. Three signals together are no longer about technology, they’re about commercial speed. That’s when the question becomes yours, not your developer’s.

Is it the code that costs a lot, or the decision you keep postponing?

The price of a redesign is visible: it’s written on a quote, all at once, and it hurts when you read it. The price of waiting is invisible. It’s spread over a whole year, in development days that produced nothing new, in dates pushed back, in contracts you didn’t sign. Nobody ever adds it up, and that’s precisely why it wins.

What it costs you

Three numbers to write down with your own data, not ours: the average lead time of a new feature today, compared with the same lead time a year ago; the share of your development days that goes to fixes rather than new work; the contracts waiting for an answer the product can’t give. Until those three numbers are on a sheet of paper, “redesign or not” remains a feeling. We won’t quote a percentage until the source has been verified and dated: an approximate figure in an article serves the article, never the decision.

Should you repair, rebuild part of it, or start over?

There are three possible answers, and the most spectacular one is the rarest.

Repairing is enough when the signals are isolated and the product already does what you’ll ask of it in two years. That’s upkeep: you stabilize, you document, you put guardrails back. Cheap, barely visible, often the right answer.

Rebuilding part of it is the most common case, by far. The database holds, payments hold, but the screens, the access rules or the billing were written for a company that no longer exists. You keep what carries the load, you redo what blocks you, and the budget is a fraction of a blank page.

Starting over is only justified when the foundations themselves prevent the next step: when every fix opens two new problems, when nobody can predict the effect of a change. It’s a rare choice, and it has to be demonstrated. It isn’t decreed because a new team would rather start from zero.

What we’d do

We start by looking, not by proposing. Five days of audit on the product as it runs, without touching it, to separate what holds from what costs you, and to rank what blocks sales. Only then, a redesign in batches: the designs before you sign, a fixed price for a written scope, and a gradual go-live. Your customers don’t see the work, and you keep the right to stop at every milestone.

When should you deal with it?

The worst moment is the one the product forces on you: an outage in front of a large account, a security audit before a fundraise, a developer leaving with the only map of the territory. At that point you no longer choose the timing, the budget or the agency.

The right moment comes earlier than it seems, and it has a very recognizable signature: the day a commercial decision starts to depend on a technical lead time. You give up an offer because it “would take too much work.” You push back a customer because it would need access rules that don’t exist. That day, the V1 is no longer slowing you down: it’s deciding for you.

The founders who have done it all say the same thing: their only regret is not starting sooner.

Frequently asked questions

Does a redesign mean throwing everything away?

No, and that’s actually the exception. In most cases part of the product holds up very well: the data, the payments, sometimes the whole business logic. The question is never “all or nothing”, it’s “what, and in which order.” That’s what the audit settles, before we talk about budget.

Can we keep selling during the work?

Yes. The redesign is delivered in batches and goes live gradually, with the old and the new running side by side until the switch. You don’t close up shop during the work, and your customers have nothing to relearn overnight.

What if the problem comes from my team rather than the product?

It happens, and we say so when we see it. An audit looks at the product, but it also shows how decisions get made: who can step in, what is written down, what isn’t. If the right answer is to organize rather than rebuild, you’ll hear it before signing anything.