The cheapest week is the one before the build.
A written specification, a fixed-price quote and a delivery date. Or an honest assessment that you should buy something instead, change a process, or not build it at all. You keep the document either way.
- 1 – 2 weeks
- start to signed spec
- Fixed price
- the spec is yours either way
- Yours to keep
- take it to anyone
Who this is for
You probably need this if…
01
Everyone describes it differently
Ask three people what the system should do and you get three answers. Building before resolving that is exactly how scope creep starts.
02
Your quotes vary by four times
Because each firm quietly guessed at a different project. A written specification is what makes quotes comparable to one another.
03
You are about to acquire software
And you need somebody technical to read the codebase before the price is agreed, rather than during the first month afterwards.
What we build
The work, in detail.
Discovery
Sitting with the people who do the work today and watching the process, because what people describe and what they perform are different.
Written specification
Screens, rules, edge cases, and what is explicitly out of scope. The out-of-scope list is the sentence that prevents the week-three argument.
Fixed-price quote
A number and a date quoted against the spec, which does not move after you sign it. Comparable against any other firm's quote.
Technical due diligence
Reading an existing codebase, or one you are acquiring, with a plain assessment of risk, licence exposure and key-person dependency.
Roadmapping
Sequenced by dependency and value, so the thing unblocking everything else is not accidentally scheduled for month five.
Build versus buy
Honest analysis of where existing software is already enough. Sometimes the conclusion is that you do not need us for this part.
Platform selection
Choosing a processor, a cloud or an auth provider against your constraints rather than against what is currently fashionable.
Feasibility
What is genuinely achievable in four weeks, what needs twelve, and which part of the idea is carrying most of the risk.
Practice areas
The disciplines behind it.
You buy this as one engagement at one price. Underneath, it draws on 3 of our practice areas, and the same people cover all of them.
Product Strategy
Deciding what to build, before spending four weeks building it.
- Discovery & scoping
- Written specification
- Technical due diligence
- Roadmapping
Design & Experience
Interfaces people can use without being trained on them.
- Product UI design
- Interaction design
- Design systems
- Prototyping
Modernisation & Migration
Replacing the system everyone is afraid of, without a weekend that goes wrong.
- Legacy assessment
- Strangler migration
- Monolith decomposition
- Re-platforming
How it runs
Four weeks, in order.
Day 1 – 2
Watch
Time with the people who do the work now. Screen recordings, the spreadsheet they actually use, and the workaround nobody mentions in meetings.
Day 3 – 5
Draft
Screens, data model, rules and edge cases written down, with the out-of-scope list drawn up alongside it.
Day 6 – 8
Challenge
We walk the draft through with your team and try to break it. Cheaper to find a wrong assumption here than in week three of a build.
Day 9 – 10
Quote
Final specification, a fixed price, a delivery date and a phased plan if it is bigger than one engagement. Signed, or not, with no pressure either way.
What you get, concretely
- A written specification: screens, rules, edge cases, exclusions
- A fixed-price quote and delivery date against that spec
- A dependency-ordered roadmap where it spans phases
- Build-versus-buy analysis where existing software would do
- A technical risk assessment of anything you already run
- The whole document is yours, whoever ends up building it
- Deducted from the project price if you proceed with us
Typical engagement
Fixed price · one to two weeks
If you proceed with the build, this comes off the project price, so choosing to scope properly costs you nothing. If you do not proceed, you keep the specification and can take it to any firm you like.
Technology
What we build it with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Discovery
- Process observation, stakeholder interviews, workflow mapping
- Output
- Written specification, fixed-price quote, delivery schedule
- Assessment
- Codebase review, dependency and licence audit
- Planning
- Dependency-ordered roadmap, milestone definition
Questions
What people ask before signing.
- Is this just a sales process with an invoice attached?
- No, and the deliverable is the proof: you keep the specification whatever you decide, including if you take it to a competitor. A sales process does not hand you something useful when you say no.
- What if the spec says it is bigger than we thought?
- Then you found out in week one for the cost of a week, instead of in month three for the cost of a project. That is the entire reason for doing it first.
- Do we have to build it with you afterwards?
- No. The quote is an offer, not an obligation, and roughly the same document would let another firm quote against it accurately.
- Can you assess a company we are acquiring?
- Yes. Codebase review, dependency and licence audit, key-person risk, and a plain assessment of what the technical debt would cost to clear after the deal closes.
- Do you write roadmaps for internal teams?
- Yes, including where the recommendation turns out to be that your own team builds it. We are not obliged to be the answer to our own assessment.
- What if you conclude we should not build it?
- You get told that, with the reasoning and the alternative. It costs us a project and it is the right answer, which is what makes the recommendation worth paying for.
Related reading
Written on this, by us.
How We Work · 8 min read
What Actually Goes in a Software Specification
A specification you can quote against is not a wish list. Here is what a useful one contains, what it deliberately leaves out, and how to tell a weak one.
How We Work · 8 min read
How to Replace a Legacy System Without a Bad Weekend
Big-bang rewrites fail at a famous rate. The alternative is slower on paper, far more likely to finish, and keeps the business trading the whole way through.
Business & Strategy · 6 min read
When an Embedded Engineer Beats a Headcount
Hiring is the right answer more often than agencies admit. Here is the honest comparison, including the cases where you should not hire us.
Tell us the problem, not the solution.
Describe what is going wrong today rather than the software you think you need. You leave the first call knowing whether it is worth building at all.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits