The five phases we run every project through

Why a process, not a to-do list

Most software projects fail slowly. Not in a fire, in a drift. The brief was written, the tickets were opened, the sprints ran on schedule — and six months in, nobody can quite explain what the thing does or who it is for.

The fix is not more tickets. It is a shape. A small number of phases that each end with something concrete, so drift shows up before it gets expensive.

This is the shape we run. Five phases, each with an exit. The exits matter more than the names.

Phase 1: Discover

The goal of Discover is one thing: to understand what you are actually trying to buy.

Half of the briefs we get describe a solution — a dashboard, an app, a rebuild — and skip the problem. That is fine as a starting point. It is not fine as a specification. Discover exists to work back to the outcome, then forward to a scope that can be built.

Concretely, one call. Sometimes two. We ask what changes for the business if this ships, what the current path looks like without us, and who is going to own it once it is in production. We write it up and send it back within one business day so you can see whether we heard you correctly.

Exit criteria: a written scoping note. It has a stated outcome, a list of what is in and out, and a rough shape. If we cannot write that note honestly, we do not have a project yet.

Phase 2: Research

Research is short, targeted, and expensive to skip.

We do two kinds. User research if the product touches people who are not you — enough conversations to know what the current job looks like, what breaks, and what a better version would need to do. Tech research on anything load-bearing: a payment provider we have not used before, a data model that has to survive migration, a compliance requirement that shapes the architecture.

The point is not to write a report. The point is to eliminate the research risk that will otherwise show up mid-build as "actually, this cannot work the way we planned."

Exit criteria: a short document — usually a few pages — that names the constraints, the users, and the decisions we now believe are safe to bake into the build.

Phase 3: Build

Build is the phase everyone thinks of when they think of software work. It is also the phase most studios run wrong, because they treat it as one thing.

We treat it as two.

First, a prototype. In about two weeks we put an interactive version of the core flow in your hands. Not a Figma file. Not a click-through. Software you can actually use — even if what's behind it is mocked data, hardcoded state, or whatever is fastest for us to iterate on with you. The point is not fidelity; it is feel. Once you have used the flow for a day, you know what the product needs to be in a way that no design review can replicate.

We iterate on the prototype together — for as long as it takes to be right. That is where the shape of the product settles. Only then do we do the second thing.

Then, we lock scope and estimate. With a prototype you've helped shape, the estimate is a number, not a range. You sign off on it before the real build begins. From there the disciplined build starts on the right stack, with the right foundations — production code, test coverage, monitoring, everything the prototype was deliberately allowed to skip.

Exit criteria: a running product that meets the acceptance criteria we wrote in Discover, tested and reviewed.

Phase 4: Launch

Launch is not a milestone. Launch is a phase, and it has real work in it.

We do the deployment. We set up monitoring — actual monitoring, not a dashboard nobody looks at — with alerts pointed at somebody who answers when it goes off. We write the handover documents your team will need to run it. We onboard your people to the codebase, the tooling, and the operational rituals we have used to keep it stable.

We watch the first traffic. We fix what surfaces. We do not disappear the day the DNS flips.

Exit criteria: the product is running in production, your team can operate it, and we agree on what happens next.

Phase 5: Grow

Most agency engagements end at Launch. That is where a large percentage of the value leaks out.

The version that ships in Launch is the version informed by two weeks of prototyping and however long of building. The version that users actually need — after they have lived with it — is a different product. Grow exists to close that gap.

Grow is a monthly cadence. Every month we ship a working improvement against a stated goal. The goal moves with the business. Some months that is a feature. Some months it is a performance rewrite. Some months it is deleting things nobody uses. All of it happens against the same product, with the same team, with the same standards.

We do not do Grow for every client. Some products should be shipped and then left alone. That is a legitimate outcome. But if a product is core to the business, the ongoing work is where it earns its keep — and Grow is how we run it.

Exit criteria: none, by design. Grow ends when the business outgrows it, or when we agree the product does not need it anymore.

What the phases force

Naming the phases is easy. What matters is what each exit forces.

Discover forces a written outcome before anyone opens a code editor. If we cannot describe what changes for you when this ships, we do not build it.

Research forces the hard questions early. The ones that would otherwise surface as change requests six weeks in, when they are ten times more expensive.

The prototype forces the honest conversation. Nobody argues with a working product the way they argue with a mock. The prototype turns the vague "I think we want it like this" into "we tried it, and this is what needs to change."

Launch forces operational readiness. A product your team cannot run is not a product. It is a demo we happened to ship.

Grow forces continued discipline. The moment a product goes into a maintenance mode, it starts to decay. Grow keeps it in the same posture that got it built well the first time.

The rule

The phases are not the process. The process is the exit at the end of each phase.

We do not move forward without meeting one. That is the whole discipline. Everything else is variation on the same theme.

If this is the shape of work you want run against your product — send us a short brief. We reply within one business day.