Engineering services
Product Planning
Before anything gets built, we work out exactly what you need, what it will cost and how long it will take — so there are no surprises halfway through.
Part of your product’s journey
Of the eight stages we run, this service covers Plan. We also run the others.
What this makes possible
Most software projects do not fail while they are being built. They fail in the weeks before, when nobody wrote down what was actually being made. The brief says “a booking platform”. Four people in the room each picture something different. Work starts anyway, because starting feels like progress. Three months later the disagreement finally surfaces, and by then the fix is a rewrite.
Our approach in more detail
Planning settles that while it is still cheap to settle. We turn the business goal into a plain description of the system. That covers what the product does and what it deliberately does not do. It also covers what information it holds, which outside services it depends on, and what happens when a lot of people use it at once. Every one of those carries a cost. Every one is easier to change in a document than in a live product.
What you get is not a pitch deck. It is a set of documents your team can act on and an outsider can check. They cover what is being built, what is not, how the pieces fit together, and what information the system holds. They also cover which outside services it connects to, the order of work, the risks, and an estimate with its assumptions written beside it. It is written so any competent team can build from it. A plan only one supplier can follow is a way of locking you in, not a plan.
What you get
- A written list of what is being built, and what is not
- A diagram showing how the pieces fit together
- A plan for what information you keep and which other systems it connects to
- A delivery plan broken into stages
- A written list of the risks and the assumptions we made
- An estimate of the effort and the running costs
How we get there.
- 01
Discovery sessions
Two to four working sessions with the people who hold the real constraints — usually a founder or product owner, plus whoever will have to run the thing day to day. We are after the decisions nobody has made yet. What happens to your existing customers. Who approves what. Which regulator, auditor or finance team has an opinion.
- 02
Scope, written down
Requirements as a numbered document: features, who is allowed to do what, the stages a thing moves through, and the awkward cases. Beside it, an explicit list of what is not included. That second list matters more than the feature list. It is what you point at in month three when somebody asks why the reporting section was never built.
- 03
How the pieces fit together
A design that suits the traffic you actually have and the budget you actually have, not the traffic you might have in five years. You get a diagram of the system and a map of the information it holds, showing how those pieces relate to each other. You also get a list of every outside service it depends on, with a note on what happens when one of them is down. And a written note on each significant trade-off.
- 04
Order of work and estimate
The roadmap is ordered so something usable exists early, rather than everything arriving on the last day. Each milestone gets a written definition of done. Effort ranges come with their assumptions beside them, plus a line for the monthly cost of running the thing, which teams routinely forget until the first invoice arrives.
- 05
Walkthrough and handover
We present the package, argue about it, and revise it. You keep every file. If you want us to build it, this becomes the basis of a fixed-scope quote. If you do not, nothing in the document assumes we are involved.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if the build is already underway and the plan is needed to justify a decision that has been made. We write what we find, and if the design will not hold up, that is what the document will say.
- Not for you if you need a proposal by Friday. Discovery needs your people in the room. A plan written without them is a guess in a nicer font.
- Not for you if the problem is genuinely small. A five-page brochure site does not need a planning document, and that money is better spent on the site itself.
- Not for you if a product you can simply buy already solves this. We will check. If a subscription tool covers it for a fraction of the cost of a build, we will say so and the engagement stops there.
- Not for you if scope cannot be settled even provisionally, because you are still testing whether there is a market. Build a rough prototype first.
A worked example
Hypothetical scenario
Illustrative: a two-sided marketplace
Say you want a marketplace where customers book approved providers. On the surface it is a listing page, a calendar and a payment. Planning surfaces what sits underneath. Who holds the money between the booking and the job being done, and does that give you the obligations of a payment middleman? When a provider cancels, is it a refund, a reschedule or a penalty, and who decides? Does a provider see the customer’s phone number before the job is confirmed? How is a dispute recorded, because sooner or later there will be one you have to answer with evidence. Each answer changes what information the system stores, and some change how it is built. A plan of this shape runs three to five weeks. It often ends with the recommendation that phase one launches in one city with providers approved by hand, because the automated approval flow held a third of the estimate.
An illustration of our approach, not a delivered client project.
How long does planning take?
Three to five weeks for a product of moderate complexity: a few types of user, a handful of outside services, one way of taking payment. Simple internal tools land in about two. Anything involving regulated data, several old systems, or moving existing records across takes longer, because the questions are genuinely harder. We give you a duration before we start, with the assumptions it rests on written down, and we hold to it.
We already have a half-built version. Is planning still worth it?
Often more so, though it becomes a different exercise. We read the existing code and the setup it runs on first, then plan forward from what is already there. The document says which parts are worth keeping, which are cheaper to replace than to repair, and what each path costs. Sometimes the honest answer is that the code is fine and the real problem is that nobody has owned it for six months.
Do we have to build it with you afterwards?
No, and the documents assume you might not. You own every one of them outright. Teams take these to their own developers or to another agency regularly. Everything is written so an engineer who has never spoken to us can work from it. That covers the diagrams, the description of what the system stores, and the agreed rules for how the parts talk to each other.
Will you give us a price for the build at the end?
An effort range for each milestone, with the assumptions written beside it, so you can challenge an assumption rather than argue with a total. What drives the number is usually how many outside services are involved, whether existing data has to be moved across, and whether a compliance rule applies. If you want a fixed price for the build, the plan is what makes one possible.
Can you plan around a team we already have?
Yes, and the plan changes accordingly. If you have two backend engineers and no designer, the order of work should reflect that rather than assume a team we would have staffed. We will also say where your team is short, because a roadmap that assumes people you do not have is a roadmap that slips.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.