The six stages of building a digital product

The two questions I get asked more than any others are “how long will this take?” and, once we’re underway, “so where are we up to?”

They sound like scheduling questions. They aren’t. Underneath both is something much more useful: what kind of work are we doing right now, and what should we be optimising for? Because the honest answer is that a product is a different animal at every point in its life, and the thing that makes you successful in one stage will actively hurt you in the next.

So years ago I drew this, and I’ve been refining it ever since. It’s the map I use with every client, and I use it on our own products too.

Three phases. Six stages. Two thresholds and two loops. Let me walk you through it properly, because every part of that picture is doing a job.

How to read the picture

Before the stages themselves, the shape of the thing tells you a few important truths.

The blocks taper. They start tall and get narrower as you move right. That’s the funnel - lots of ideas go in the left-hand side, and very few come out the right. That’s not failure, that’s the process working. If everything you start makes it all the way through, you aren’t taking enough shots.

The fill gets solid. Ideas is just an outline - there’s nothing real there yet. Validation is half filled in. Architecture and build is solid. Your commitment, your spend and your risk all increase together, and the diagram is deliberately honest about the fact that the outline stage costs you almost nothing while the solid ones cost you nearly everything.

Launch spikes back up. Look at the height of “Launch + Fire fighting”. After the tapering-down of the first three stages, the effort jumps straight back up again. This is the single most misread part of building a product, and I’ll come back to it, because almost everybody thinks launch is the finish line and it is emphatically the start line.

MVP and Ver 1.0 are dashed lines, not blocks. They’re thresholds you cross, not stages you occupy. You don’t spend three months “doing MVP”. You cross it, in a moment, and everything about the work changes on the other side.

BAU never ends. The green block runs off the right-hand edge and keeps going. There’s no completion state. I’ll come back to that too.

The whole thing is built on the Lean Startup framework by Eric Ries, with twenty-odd years of our own scar tissue layered on top.

Phase one: Prototype

Focus: cost to launch

Everything in the red phase is in service of one goal - getting something real in front of real customers for the least money possible. Every decision gets measured against that. Not “is this good?” Not “is this how I’d want it forever?” Just: does this get us to a customer faster and cheaper?

Stage 1: Ideas

You’ve got a few, and you’re doing your research on the market you want to get into.

I need to say something unpopular here, gently. Ideas are worth approximately nothing. A lot of people think - and a lot of people will happily sell you on the notion - that a good idea is an asset with real value. In monetary terms it just isn’t, not until you’ve built it and somebody has willingly handed you money for it.

In fact, before that moment, an idea is closer to a liability. It’s the thing that’s about to make you spend a great deal of money with no income to offset it. That’s not a reason not to have ideas. It’s a reason to get through this stage cheaply and quickly, and to fall in love with the problem rather than your particular solution to it.

Notice the block is an unfilled outline. Nothing real exists yet.

Stage 2: Validation

You’re not put off by any of that, so you narrow down to an idea or two that look like they might fly. Now you give those ideas some actual value by testing them on potential customers.

And I mean real customers. Not your mates, not your partner, not your mum. People who have no emotional investment in you whatsoever and will either buy the idea before it exists or tell you to your face that it’s rubbish. It is a genuinely uncomfortable thing to do, and it is by an enormous margin the fastest way to kill your bad ideas and find your good one.

At the same time you’re working on the business model. How does this make money? Who do we need to support customers? What structure do we want? These are not questions for later - later is far too late.

Stage 3: Architecture and build

You’ve picked the one. Now you need specialists to bring it to life, and money to pay them.

Assuming the money’s sorted and you’ve found a technical partner, you start by gathering every business requirement you have and explaining it carefully and deeply to your architect. Their job is then to question and pick your business apart until they’re confident they can build something close to what you actually need - which, as I’ve written about before, is not always the same as what you asked for.

What you’re constructing here is your first Value Attempt - an honest guess at something somebody will value enough to pay for. The output is a Minimum Viable Product: the smallest thing that gets your idea into customers’ hands so you can validate, for real this time and with real money, whether they’ll buy it. Sometimes there’s a prototype before the MVP, to prove the hard bit is even possible or to win the funding. Either way the real goal is the same - reduce risk by finding the unknowns and solving them.

This stage is also where I have watched more money burn than anywhere else in the entire diagram.

It’s rife with conflict, because this is where you want to make it really good. It’s the first time the thing feels real, and the temptation to polish is enormous. I’ve seen agencies cheerfully over-cook this stage into oblivion because it wasn’t perfect yet. Don’t do it. Every dollar spent on polish here is a dollar you cannot spend on the iteration that actually finds you a market.

Your one litmus test for every decision at this point is: does this get us to revenue? In the harsh reality of business, no money usually means the project is over - which makes it the only metric that matters yet, and makes how nice it looks almost entirely irrelevant.

⟍ MVP ⟋

You cross the line. The product is in real hands. Everything changes.

Phase two: Iterate

Focus: product market fit

The red phase was about spending as little as possible to get to the start line. The blue phase is about finding out whether there’s a race to run at all. This is where businesses are made and lost.

Stage 4: Launch and fire fighting (Alpha)

You’ve got the first version of your product and you’re ready to unleash it on the unwashed masses. It’s been a hard slog. Surely now the hard work is over.

I’m sorry. You are at the start line and you haven’t moved yet.

Picture a race track. You can see other businesses tearing around it in fast, beautiful cars, and you want in. So you’ve spent all this time and money building your own race car and you wheel it up to the grid - and it is, objectively, the most rickety hunk of junk on the track. You don’t even know if it runs, because you have never built an entire car before. Bits of one, sure. Not the whole thing.

So you start it up. It immediately catches fire. You put the fire out by fixing a problem that nobody saw coming, and you try again. You repeat this until the thing will start and roll down the road, very slowly.

That’s launch. Getting off the start line.

A lot of products die right here, because everyone spent their entire budget getting to launch, believing the money would start arriving on day one. It’s the trap that gets sold to founders more than any other. And here’s the thing almost nobody can grasp until they’ve lived it: your MVP is built on assumptions and best guesses. Only once it’s actually rolling can you see that one wheel doesn’t work and the whole thing is dragging to the left.

Which brings us to the loop tucked into the bottom of that block.

The pivot cycle

You go round and round: change something, put it in front of customers, watch what really happens, change again. You are hunting for product market fit, and very, very few people hit it on the first attempt. You’ll be adjusting your value proposition until you find a shape where people pay you money and - critically - keep using the thing afterwards.

Some products never get out of this loop. There turns out to be no market, or the validation work wasn’t rigorous enough, or something outside your control lands on you, or the founder simply won’t adapt because the idea is perfect and it’s the market that’s wrong. This stage can take years. Plenty of ideas work, sort of, but never quite enough to clear break-even.

Pro tip: if you have no fires to put out, you almost certainly over-invested in the stage before. Fires here are normal and expected. A suspiciously smooth launch usually means you spent six extra months making something nobody had asked for yet.

Stage 5: Stabilisation (Beta)

It’s been a long haul, but you now have customers who love the product and are telling their friends. Sales are steadying. There are fewer fires every day. Your support people know what they’re doing and have real processes. There’s even enough income to hire for the roles you desperately need.

Congratulations - your car is in the race and holding together.

Two things happen here that catch people out.

The first is that your language changes completely. Where you were optimising for speed, you’re now optimising for stability, maintenance and security. Release cycles slow right down. Tickets get smaller, bugs get rarer, and your testing gets more rigorous, because the cost of breaking things is now measured in real customers rather than hypothetical ones. If your technical partner isn’t changing how they talk to you at this point, ask why.

The second is that your team changes. Some of the people who were brilliant in the fire-fighting stage will go quiet and start looking around. That is completely normal and not a betrayal - the people you need to build your car are not always the people you need to run it. Early-stage people are often energised by chaos and ambiguity, and stabilisation is the deliberate removal of both.

⟍ Ver 1.0 ⟋

The product is genuinely dependable. Now you have to keep it that way, forever.

Phase three: Scale

Focus: maintenance, stability and security

Stage 6: BAU and the new feature cycle

Business as usual. The block that runs off the edge of the page and never stops.

This is the stage nobody puts in the pitch deck, and it’s the one your product will spend the overwhelming majority of its life in. Look at the diagram again - BAU and the New Feature Cycle are drawn interlocking, because from here on they’re not sequential, they’re a rhythm you keep for as long as the business exists.

BAU is the unglamorous keeping-alive: dependency updates, security patches, certificate renewals, monitoring, backups you actually test, the support queue, the slow work of paying down the shortcuts you took in the fire-fighting stage. None of it shows up as a feature. All of it is the reason you still have customers next year.

The new feature cycle is the growth engine, and it’s a smaller, calmer echo of everything you just did. Every new feature runs its own miniature version of this whole diagram - an idea, some validation, a build, a careful release, a period of watching it closely, then it settles into BAU alongside everything else. Same map, shorter journey.

The reason both are drawn as one interlocking shape is that neglecting either one kills you. All BAU and no new features and you slowly become irrelevant. All new features and no BAU and you’re building an ever-larger structure on rotting foundations, and one day it falls over during your busiest week.

This is what I mean when I tell people that technology is alive. There is no finished. There’s just healthy or neglected.

What the map is actually for

The point of all this isn’t to be a project plan. It’s a diagnostic. When something feels wrong, the most useful question is usually which stage are we actually in, and are we behaving like it?

Nearly every expensive mistake I’ve watched a business make - our own included - is a stage mismatch:

Get the stage right and most of the arguments dissolve, because you’re no longer disagreeing about the work - you’re agreeing about what to optimise for.

And it explains the thing that frustrates business owners most about technologists: why we can’t give you a date. It’s not evasion. In the red phase we’re navigating genuine unknowns and any date is a guess dressed up as a commitment. By the green phase we can be pretty precise, because we’ve done this exact thing to this exact system a hundred times. The confidence you’re asking for is a product of progress through the map, not an input to it.

Where our own products sit

It’s only fair to show my working, so here’s our shelf right now:

• Static Contact is well into BAU. Live since 2024, quietly doing its job, mostly patches and small improvements.
• Client Invoices is in stabilisation - launched, real users, still smoothing edges.
• The Mangawhai Directory is in its own odd version of BAU, where the ongoing work is data rather than code.
• FNA Manager is in beta - late stabilisation, heading for 1.0, and by a distance the biggest thing on the list.

Four products, four different stages, four completely different kinds of week. That’s the whole point of the map.

Wrap up

Iteration is king. Build small, release often, then expand - too big a jump and you fall off a cliff.

If you take one thing from this, make it this: know which stage you’re in, and behave accordingly. Optimise for cost to launch in the red. Optimise for product market fit in the blue. Optimise for stability in the green. Doing the right work at the wrong time is indistinguishable from doing the wrong work, and it costs exactly as much.

If you’re staring at this diagram trying to work out where you are - or you’ve got a horrible suspicion you’re doing green-phase work on a red-phase budget - come and have a chat. Working that out is genuinely one of my favourite conversations to have, and it’s usually a short one.