Web App Consultation
Three weeks, a fixed price, and a document that says what we would do and why. Including, sometimes, that you should not build this.
- Duration
- Three weeks
- Team shape
- One senior engineer, one architect
- Ends with
- A written recommendation
The cheapest part of a project is deciding not to do it
Most of the expensive decisions on a software project are made in the first month, by people who do not yet have the information to make them. A diagnostic is a way of buying that information before it costs a year.
This is a fixed-scope engagement with a fixed price and a written output. We look at what exists, talk to the people who use it and the people who run it, and come back with a recommendation and the reasoning behind it. You own the document. There is no obligation to build with us afterwards, and a recommendation not to build is a legitimate result rather than a failed sale.
What usually goes wrong, and what we do instead
The failure mode is not bad analysis. It is analysis that never resolves into a decision.
Where scoping goes wrong
- A requirements document that lists features and never names a trade-off
- An estimate produced before anyone has looked at the existing system
- Consultants who cannot recommend against the work they are selling
- A discovery phase that expands until the budget for building is gone
- Findings delivered as a deck, so nothing is written down precisely
How we run it instead
- A fixed three weeks and a fixed price, agreed before we start
- Time in the existing system and its data, not only in interviews
- A recommendation that can be 'do not build', and sometimes is
- Options costed against each other, with what each one gives up
- A written document you own, precise enough to build or tender from
What the three weeks cover
The same ground every time, because the gaps are usually in the parts nobody thought to mention.
01
The current system
What exists, what it costs to change, and which of today's problems are structural rather than incidental.
02
The people in the process
How the work is actually done, including the spreadsheet nobody mentions in the first meeting.
03
The data
Volumes, quality and ownership. Most surprises in a build are data surprises found late.
04
Constraints and obligations
Regulatory, contractual and security requirements, established before the design rather than after it.
05
The operating picture
Who would run this, what they can support, and what that rules in and out.
06
The options
Build, buy, extend or leave alone — costed against each other rather than assumed.
How we reach a recommendation
Four questions, asked in order. A no at any of them changes the answer, and we say so rather than continuing to the next.
Is this the real problem?
The stated problem and the underlying one are frequently different, and building the wrong one is expensive.
- What would change for the business if this were solved
- Whether the same outcome has a cheaper route
- Who has tried this before here, and what happened
Does it need building?
Software is the answer less often than a software company usually admits.
- Whether a package exists that fits without reshaping the process
- Whether the process itself is the constraint
- What the honest cost of ownership looks like over three years
Can it be operated?
A system nobody can run is a liability regardless of how well it was built.
- Who would own it after handover, and what they can support
- What skills would need to be hired or retained
- Whether the operating cost is one the business has agreed to
What is the smallest first step?
Any recommendation that starts with a twelve-month programme is a recommendation we have not thought hard enough about.
- The one slice that would prove or disprove the approach
- What it would cost and how long it would take
- What we would learn that would change the rest of the plan
What you end up with
Stated from your side rather than ours.
A document you can act on
Precise enough to build from, tender from, or take to a board, and written to be read by people who were not in the room.
An answer that can be no
We are paid for the diagnostic rather than for what follows it, which is what makes a recommendation against building possible to give.
Options with their costs attached
Build, buy and extend compared against each other, so the decision is a choice rather than a default.
A defensible first step
The smallest piece of work that would tell you whether the rest is right, sized and costed.
How the three weeks run
The same five stages as every engagement, compressed into a fixed scope.
Diagnose
Week one: the system, the data and the people. Mostly listening, and reading code.
Decide
Week two: options developed and costed, and the trade-offs made explicit.
Prove
Where a technical risk decides the answer, we build the smallest thing that tests it rather than reasoning about it.
Deliver
Week three: the recommendation written, then walked through with the people who have to act on it.
Hand over
The document is yours, including if you take it to somebody else to build.
What you get, and when
One document, and the working material behind it.
- What exists today and what it costs to change
- The data picture, including quality and ownership
- Constraints and obligations we found rather than were told
- Build, buy, extend or leave alone, costed against each other
- What each option gives up, stated plainly
- The risks that would change the answer
- One recommendation, with the reasoning that produced it
- A sized and costed first step
- A walkthrough with your team, and the document to keep
Where it can lead
Three of the seven ways we work. Which one follows a diagnostic depends on what the diagnostic found, and none of them is the default.
Discovery / Assessment
A time-boxed investigation that ends in a written recommendation, including the recommendation not to build. You can act on it with us or without us.
Best when the problem is agreed and the solution is not.
- Where it fits: a business case nobody can evidence, or a system everyone blames.
- A written problem statement, the options considered, and the reasoning for each.
- You own the decision at the end; we own the evidence behind it.
Consulting / Advisory
Senior engineering judgment applied to decisions you are already making — architecture, vendor choice, a rebuild someone has proposed. No delivery attached.
Best when you have the team but not the second opinion.
- Where it fits: an in-house team facing a decision it cannot take twice.
- Architecture review, technology selection, or a rebuild proposal tested before it is funded.
- You own the decision and the delivery; we own being right about what we told you.
Fixed-Scope Delivery
A defined piece of work, scoped and priced up front, delivered end to end. Scope changes are re-priced in the open rather than absorbed quietly.
Best when the scope is stable enough to write down and hold.
- Where it fits: a replacement, an integration, or a first release with firm edges.
- Fixed budget, so the risk of a wrong estimate is ours, not yours.
- We own scope, estimate and delivery risk; you own acceptance.
The rest of our web work
Most web engagements touch two or three of these. If you are not sure which, the consultation is the way in.
Related work
Engagements where the decision mattered as much as the delivery.
Questions about the diagnostic
The ones we are asked most often before a first conversation.
What does it cost?
Do you actually recommend against building?
Do we own the document?
How much of our team's time does it take?
We have no system yet. Is this still relevant?
Are we committed to building with you afterwards?
Not sure whether to build this?
Tell us what you are trying to decide. Three weeks is usually enough to answer it properly.