Deciding what to build before building it: scoping the work, cutting it to something shippable, and putting a fixed price against it.
What this covers
The work that happens before any code, and that determines whether the code was worth writing.
Turning a broad ambition into a specific, buildable scope.
Separating what has to exist at launch from what can wait, honestly.
Sizing the work, so the budget conversation happens early rather than at the end.
Mapping how the software fits the process around it, including the parts that stay manual.
How the work runs
A short, concentrated engagement rather than a long consultancy. We spend time with the people who will use the thing, not only the people commissioning it, because the gap between those two accounts is where most rework comes from.
The output is a written scope you could hand to any competent team, with the decisions and their reasoning recorded, including the options we rejected, so nobody relitigates them in six months.
It ends with a fixed price and a timeline against that scope.
What you have at the end
A document that makes the project fundable and buildable, and is yours whatever you do next.
A defined scope, prioritised, with what is out of scope written down as plainly as what is in.
A fixed price and timeline for building it.
The reasoning, so a decision can be revisited on purpose rather than by accident.
You are free to take that document elsewhere. It happens, and the work was still worth doing.
Who this suits
Anyone who has been quoted wildly different prices for what they thought was the same project: that spread is almost always a scope that has not been pinned down.
Also teams who know something needs building but cannot yet write down what "done" looks like.
What you can bring to us
A startup idea that needs an MVP scope before you spend money on it.
A project that needs a written specification, so that quotes can be compared fairly.
An internal tool or digital product your company has discussed for a year.
An existing product where nobody agrees on what to build next.
This is software product consulting from people who write the code, so the plan is checked against what building it really takes.
The process, step by step
Briefing: What you want to achieve, for whom, your budget range and what you already know or have tried.
User and market research: Conversations with the people who will use it, and a look at what they use now, including competing products.
MVP scope: Features split into what launch needs, what can wait and what should be dropped, with the reasons written down.
Technical plan: How it would be built, the main risks, and flows or wireframes where words are not enough.
Roadmap and fixed price: A delivery plan, plus a fixed price to build it with us. The document is yours to take anywhere.
From an idea to a buildable plan
What goes in, what gets decided, and what you hold at the end.
What you bring: The idea, Goals and budget, Your users, What exists today
What we examine: User needs, Competing products, Technical risks, The process around the software
What gets decided: MVP features, What waits, What is dropped, Technology choices
What you receive: Written specification, Wireframes, Product roadmap, Fixed price and timeline
Frequently asked questions
What does product strategy include?
Research with your users, a prioritised MVP scope, a technical plan and a roadmap, ending in a written specification and a fixed price to build it.
Why not go straight to development?
You can, if the scope is already clear. If you have been quoted very different prices for the same project, that usually means the scope is not pinned down, and this work is what fixes it.
Am I obliged to build with you afterwards?
No. The specification is yours and any competent team can quote against it.
How do you decide what goes into the MVP?
We ask what a customer would pay for or a team would rely on from day one. Anything that a real user can live without at launch waits, and that decision is written down with its reason.
How long does the strategy phase take?
It is a short, concentrated engagement rather than a long consultancy. You get the exact length with the quote, because it depends on how much is already known.
Can you review a specification we already have?
Yes. We read it, point out the gaps and risks, and quote against it if it holds up.