What the Blueprint stage actually produces

Every project we take on starts the same way: one to three weeks of definition work we call the Blueprint. No code gets written during it. That sounds slow the first time you hear it, so this article says exactly what the stage produces and why we won’t skip it.

The short answer: you leave the Blueprint holding a document set that names what will be built first, the business case for building it, how long the prototype will take, and a fixed price we stand behind. You own it outright. If we turn out to be the wrong builder, you can take it to another one.

What actually happens in those weeks

Three things, and they are all work you can watch happening.

We interview the people who will use the app. Not the project’s sponsor, the people who will tap the screens on a Tuesday. What they do today, where it goes wrong, and what they quietly do in a spreadsheet because the current system can’t.

We build clickable mockups of the app and put them in front of those same people. The mockups are the argument: it is far cheaper to disagree about a screen than about a shipped feature, and every real disagreement we can move from the launch back into week two makes the prototype shorter.

And we take a hard look at the systems and data you already have. The biggest surprises in any build hide in the connections to what exists, so that is where we go looking before naming a number.

The three things you walk away with

A written description of the app. Screen by screen, rule by rule. This is the document your own people measure the prototype against while they use it, so acceptance is a comparison, not an opinion formed on the day.

A plan with real dates. The prototype is scoped in the Blueprint and lands a few weeks after it, in weekly cycles that each end with a demo of working software. What your people validate is what we take into production.

A fixed price. It holds because of the document above: nothing gets built that is not in the Blueprint, and any change comes back within two business days, written and priced, before it enters the plan.

Why the price comes after, not before

A price named before the definition work is a guess, and someone has to carry the risk of that guess. Either it is padded to protect the builder, or it is optimistic and the corners get cut later, quietly, where you can’t see them. Both are expensive; only one of them sends an invoice.

Naming the price after the Blueprint moves the guesswork out of the deal. By then we know the screens, the rules, and the systems the app has to talk to, so the number is a commitment rather than an opening move.

The honest cost: the Blueprint needs real weeks, and it needs your people. Interviews, access to your systems, answers within days rather than weeks. Definition work with nobody available produces a document about an imaginary company, and we would rather not build from one.

The short version

• One to three weeks, before any code.
• You get the app described screen by screen, a plan with dates, and a fixed price we stand behind.
• The document is yours outright, whoever builds it.
• The price comes after the definition work because that is the only order in which it can be honest.