Blueprint
A few focused weeks that turn a rough idea into a scope, a prototype and a price everyone agrees on, before serious money is spent.
The most expensive line of code is the one that solves the wrong problem. Blueprint exists to prevent it. We spend time where your software will be used, with the people who will use it, and write down what they really need in plain language. Then we test the riskiest assumptions with a clickable prototype and a quick technical spike. You finish with a plan that a developer, a designer and a finance team can all read, and the confidence to approve it.
Step by step
Five steps that take an idea from a conversation to a plan you can sign.
Listen
We visit, call or sit alongside the people who will use the software, and record how the work happens today, including the shortcuts and workarounds.
Frame
We agree the problem in one sentence, how success will be measured and which constraints are real, from budget and deadlines to devices and languages.
Sketch
We draw the main screens and flows quickly and cheaply, try several directions and throw away the ones that don't survive contact with users.
Prove
The best direction becomes a clickable prototype that real users try, while engineers test the hard parts such as payments, integrations, offline sync and data.
Commit
We write the scope, the release plan and the estimate, list the risks and how we'll manage them, and agree what goes into the first release.
Typical length
Usually two to four weeks, depending on how many people, processes and integrations are involved.
What you
get at the end
Tangible outputs, owned by you, useful the moment the phase closes.
A one-page brief: the problem, the users and how success will be measured
A clickable prototype of the key journeys, tested with real users
A prioritized feature list, split into releases
A recommended architecture and technology stack, with the reasons
A fixed-price or time-and-materials estimate for the first release
A short risk list, with what we'll do about each one
This fits when
If any of these sound familiar, this is the phase your project needs first.
You know the problem well but can't yet describe the software
Different people in the business describe the product differently
Quotes from different vendors vary wildly, and you can't tell why
You've been burned before by software that didn't fit the work
Common questions
Is Blueprint required before we build?
No. If you already have clear requirements and designs, we review them in a few days and start building. Blueprint is for when the idea still needs shaping, which is more often than people expect.
How much of our time does it need?
A few hours a week from the decision-makers, plus access to the people who do the work today. We do the writing, designing and testing between sessions.
What if the plan shows it isn't worth building?
Then we'll say so, with the reasons. Finding that out in a few weeks is far cheaper than finding it out after launch, and sometimes the answer is an existing tool rather than custom software.
Can we take the Blueprint to another vendor?
Yes. Everything it produces is yours: the brief, the prototype, the plan and the estimate's assumptions.