Software Discovery Phase: Turn Your Idea Into a Buildable Plan
Two to four weeks, a fixed fee, and a document that tells you what you are building, what it will cost, and what could go wrong. You keep it whoever builds the software.
Discuss your projectWhy pay for a plan
Because the alternative is an estimate based on a conversation. Anyone who quotes a build from a half-hour call is either padding heavily to cover what they do not know, or they will come back for more money when they find out. Neither is good for you.
Discovery converts the unknowns into written decisions. The requirement that seemed simple turns out to need an approval workflow. The integration everyone assumed existed has no API. The data model has a conflict nobody had noticed. Finding these in week two costs a conversation; finding them in month four costs a change request and a delay.
It also gives you something to take elsewhere. A specification that any competent team could quote against is worth more to you than one written to be unquotable by anyone but its author, and we write it that way on purpose.
What you get
A specification
What the software does, by user role, in language your team can check. Including what it deliberately does not do in version one — the exclusions are as important as the inclusions and are where scope disputes start.
A data model
The entities, their relationships, and who may see and change what. The most expensive thing to change after building begins, and the thing most often left until the code forces a decision.
Architecture and stack
What gets built with what, where it runs, and why — assessed against what your team could maintain, not against what is interesting to build.
Interface designs
Wireframes or clickable designs for the primary screens. Enough to find out that the workflow is wrong before it is implemented, which is the cheapest moment to discover it.
An estimate with its assumptions
A range rather than a single number, with the assumptions each figure depends on stated, so you can see what would make it move. A single number with no assumptions is a sales device.
A delivery plan and risk register
Phases, what could go wrong, and which risks are worth mitigating now rather than later.
Process
Two to four weeks depending on scope. It needs a few hours a week from whoever can make decisions.
- 01
Week one: understand the problem
Workshops with your team about the process the software serves, not the software. We ask what happens today, where it goes wrong, and what success would look like in terms you could measure.
- 02
Week one to two: model and design
Data model, user roles, permissions, and wireframes of the main flows. Reviewed with you as it is produced rather than presented at the end.
- 03
Week two to three: technical assessment
Architecture, integrations investigated for real — we check whether those APIs exist and what they actually return, rather than assuming the documentation is accurate.
- 04
Week three to four: estimate and plan
Scope split into phases, estimated with assumptions stated, and risks documented.
- 05
Handover and challenge
We present it, you push back, and we revise. A specification nobody argued with has not been read.
Who it is for
- Founders with an idea who need to know what it costs before raising or committing.
- Companies replacing a system they depend on, where getting the requirements wrong is expensive.
- Anyone who has received wildly different quotes for the same brief — which usually means the brief is ambiguous rather than that the vendors are.
- Teams that need an internal business case, where a written specification and estimate is what gets a budget approved.
- Companies whose last project overran, and who want the scope settled in writing this time.
Common questions
Related in Custom Software Development
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch