The cheapest week is the one before the build.
Scoping, technical due diligence, roadmapping, and a written specification you sign. Most failed projects were decided before anybody opened an editor.
- Week one
- written spec, no code yet
- Fixed price
- quoted from that spec
- Honest no
- if we are wrong for it
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 precisely how scope creep begins.
02
Your quotes vary by four times
Because each firm quietly guessed at a different project. A written specification is the thing that 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 this covers
The work, in detail.
7 capabilities
01
Discovery & scoping
Sitting with the people who do the work today, watching the process, and writing down what the software actually has to do.
02
Written specification
Screens, rules, edge cases, and what is explicitly out of scope. Signed before the build, which is what makes the quote mean something.
03
Technical due diligence
Assessment of an existing codebase, or of a company you are about to acquire, with a plain reading of the risk and the effort involved.
04
Roadmapping
Sequencing by dependency and value, so that the thing unblocking everything else is not accidentally scheduled for month five.
05
Build versus buy
Honest analysis of where existing software is already enough. Sometimes the answer is that you do not need us for that part at all.
06
Feasibility & estimation
What is genuinely achievable in four weeks, what needs twelve, and which part of the idea is carrying most of the risk.
07
Platform selection
Choosing a processor, a cloud, an auth provider, judged against your constraints rather than against what is currently fashionable.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Watch the work before designing the software
The process people describe and the process they actually perform are different. The gap between them is where the real requirements live.
02
Out of scope gets written down
Naming what we are not building is more useful than naming what we are. It is the sentence that prevents the argument in week three.
03
Sequence by dependency
Build the thing everything else is waiting on first, even when it is less exciting than the feature that was demoed to the board.
04
An honest no is worth more than a bad yes
If your problem is solved by software that already exists, or by a process change, we say so. It costs us an engagement and it is still the right answer.
Technology
What we work 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 risk audit
- Planning
- Dependency-ordered roadmap, milestone definition
Where this shows up in delivery
- Week one of every engagement is scope, and it produces a document you sign before any code gets written.
- We have delivered five systems end to end, so the sequencing advice comes from having made these calls under real deadlines.
- We turn down work that is better solved by software which already exists, which is what makes the recommendation worth anything.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Questions
What people ask about product strategy.
- Is the scoping week charged separately?
- It is the first week of the engagement and it sits inside the fixed price. If you decide not to continue after it, you keep the specification and can take it to anybody.
- What if the spec says the project is bigger than we thought?
- Then you found that out in week one for the cost of a week, rather than in month three for the cost of a project. That is the entire reason for doing it first.
- Can you do due diligence on 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.
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.
Usually combined with
All practice areas →Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
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