Product strategy
Product strategy and fixed-price software project scoping
Turn an early software idea into a costed, buildable plan
Before a single screen is designed, we get clear on the business case — who it's for, what success looks like, and what to build first.
Live mockup
From vague brief to a plan you can fund
Watch a messy “build everything” request turn into a clear audience, a first version worth funding, a technology recommendation, and a fixed quote with a timeline.
Strategy board
Vague brief → fundable plan
Incoming brief
“We need an app for everyone — bookings, loyalty, AI, multi-location… ASAP.”
Audience clarity
Who is this really for?
MVP now
- Sorting…
Later phases
- Parking lot…
Stack advice
Timeline you can plan around
Autoplay — brief → audience → MVP vs later → stack → fixed quote
Who it’s for, before what it does
We establish who buys it, who uses it daily, and who signs it off — so the first version is built for someone specific rather than everyone in general.
What launches now, what waits
Good ideas that aren’t urgent are held for later phases. What you fund first is the smallest version that can win a real customer — the MVP, and the reasoning behind where the line falls.
The right technology for the job
A technology recommendation tied to what you’re actually building and what your timeline can carry — not whichever tools happen to be fashionable.
A quote you can plan around
A fixed price, dates on a calendar, and a number you can take to finance — not an open-ended bill that grows as the work goes on.
What you receive
A document you can build from
Scoping is the part of the process most often sold as a discovery workshop and delivered as a slide deck. This is what you actually get instead — a written plan specific enough to quote against and build from.
Who is the product actually for?
Not personas. The specific people who will use it, which of them holds the budget, which of them uses it daily, and what each one needs it to do. Most projects go wrong because this stayed vague and everyone assumed a different answer.
What gets built first, and what waits?
An explicit split between the MVP and the later phases, with the reasoning attached. The point isn’t to cut your scope — it’s to get something in front of real users before the budget is committed to features nobody has tested yet.
Which technologies will it be built on?
Which technologies we recommend building on, and why those rather than the alternatives. Written clearly enough that the constraints are legible to anyone who needs to work within them.
How is the price fixed?
Not an estimate or a day rate. A number, tied to the scope above, that holds unless you change the scope. Changes get quoted separately so you always know what you have committed to.
How long will it take?
Phases with dates, including what we need from you and when — because the most common cause of a late project is content or approvals sitting with the client.
You leave with a clear, costed route into development and a shared understanding of what should happen next.
What's included
- Who the product is for, decided
- A first version defined, and what comes after
- Technology recommendation and feasibility check
- Fixed quote and timeline you can plan around
You leave with a written plan, not a vague workshop — a clear, costed route into development.