One technical decision, answered by someone with no stake in it
Software Development Consulting
Some technical questions do not need a standing advisor, just one honest, informed opinion before real money gets committed. This practice exists for exactly that. A stack choice, a review of why a project has stalled, or an assessment of a vendor's technical claims each gets delivered as a bounded engagement with a clear end point.
How a single technical decision gets answered here
Stack selection, project diagnosis and vendor evaluation, each scoped as its own engagement.
90 secSample frame · video pending01Before booking a review
Is the gap technical, or is it delivery?
A stalled project sometimes needs an architecture fix and sometimes needs a scope or estimate fix instead. Four questions settle which kind of review actually fits.
Has the codebase itself become hard to change?
Structural fragility points at an architecture review. A codebase that is fine but constantly re-prioritised points at a delivery or scope problem.
Is a purchase decision imminent?
An approaching vendor contract benefits from a technical evaluation before signature, not after the commercial terms are locked in.
Do internal accounts of the problem disagree?
Conflicting explanations for a stall are a strong signal an outside, evidence-based diagnosis will land better than another internal retrospective.
Is this a one-time question or a recurring pattern?
A recurring pattern of stalled decisions points toward standing leadership rather than another one-off consulting engagement.
| Architecture review | Stalled-project diagnosis | |
|---|---|---|
| Typical trigger | A new build or major refactor | Delivery has slowed unexpectedly |
| Main output | A stack or design recommendation | A root-cause diagnosis and fix list |
| Evidence used | Requirements and constraints | Delivery history and team accounts |
| Best fit | A decision not yet made | A decision already made, not working |
02Agreed before the review starts
The ledger that keeps the engagement honest
Consulting reviews drift when a bounded opinion quietly turns into unpaid implementation work. This ledger sets out what you bring, what we review, what comes back, and what remains under your authority.
- Your side
You bring
- The product requirements and expected scale
- The team's existing skills and stack preferences
- Any constraints on budget, timeline or hosting
- Our side
We build
- A comparison of realistic stack options against the actual requirements
- A recommendation weighted by team skill and long-term maintenance
- A written rationale the team can reference after the decision
- Your side
You receive
- A stack recommendation with the reasoning attached
- A shortlist of viable alternatives and why they were set aside
- A brief scoped tightly enough for a build team to start from
Never leaves you
- The final stack decision and the build itself
- The team that will maintain the product going forward
- Every vendor or hosting relationship chosen as a result
Where the line sitsThe recommended stack is the one your team can operate confidently, not the one that reads best in a comparison chart.
03From access to a written recommendation
Four stages, each closing on a written artefact
Consulting reviews that drag usually skipped one of these stages. This system closes each one with a decision you can put to work right away.
Gather the codebase, history and accounts
Access to the relevant system, delivery history and honest team accounts get collected before any opinion gets formed.
Evidence gathered, not assumedCompare the realistic options
Stack, architecture or vendor options are weighed against your actual requirements and team capability, not a generic checklist.
Options weighed against the real constraintsWrite the recommendation down
The finding and its reasoning are captured in a document built to survive scrutiny weeks after the engagement ends.
A recommendation you can defend laterHand off with next steps named
Whoever acts on the recommendation, your team or another vendor, inherits a clear, ranked list of what to do next.
A decision ready to act on
04What actually moves the number
Four drivers, priced from a short scoping call
Software development consulting is priced as a small, fixed engagement, because these four factors change its depth without changing its shape.
Size and complexity of the system in question
Reviewing a single service is faster than assessing a sprawling application with years of accumulated decisions.
How much delivery history needs reconstructing
A stalled project with thin documentation takes longer to diagnose than one with clear records of what was tried.
Number of vendors or stack options under comparison
Comparing two clear finalists is quicker than an open-ended evaluation across many unfamiliar options.
Whether a written, presentation-ready report is required
An internal-only recommendation costs less than a report built for a board or an external stakeholder.
05Evidence and proof
Decisions that held up after the review ended.
Consulting proof here is a recommendation that still looks right once the pressure of the decision has passed. Every record here waits for written client approval before production.
Explore case studiesA stack decision that avoided a costly rebuild eighteen months later.
Tern's team was split between two frameworks for a new logistics module. A consulting review recommended the option that matched their existing skills, avoiding a stack nobody could maintain.
- Time to a written recommendation
- Two weeks
- Team consensus reached
- Unanimous after review
A stalled project traced to scope, not the engineering team.
Orra Systems assumed a stalled feature meant their engineering team was underperforming. A diagnosis found an unrealistic original estimate was the actual cause, and a revised scope restarted delivery.
- Root cause identified as
- Scope, not team performance
- Delivery resumed within
- One sprint cycle
They told us the vendor we already preferred had a real integration risk. We renegotiated the contract before signing.
Sample · pending client approval
06Read this first
When a single consulting engagement is the wrong move
Paying for a one-off review when the actual gap is recurring leadership just delays the fix. The exits are marked plainly.
- CTO as a Service
This is the third stalled decision this year, not the first
A recurring pattern of stuck decisions points toward standing technical leadership rather than repeated one-off reviews.
- Product engineering
The gap is build capacity, not a decision
If the direction is already clear and the team just needs more engineers, a dedicated build team fits better than a review.
- Digital Transformation Consulting
The decision spans an entire estate of systems
When the question touches several systems and processes rather than one build, a transformation roadmap fits the scope better.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Single review | One decision needs an outside opinion | The final call and its timing | Diagnosis and a written recommendation |
| Review into build | You want continuity from decision to delivery | Priorities as the build proceeds | Recommendation, then the build itself |
| Recurring advisory | Stalled decisions keep recurring | Product and company direction | Standing technical judgement over time |
07Straight answers
Asked before a technical decision is finalised.
01How is this different from a fractional CTO engagement?
This practice answers one specific technical decision and closes. A fractional CTO takes ongoing responsibility for technology judgement across many decisions over time.
02Can you evaluate a vendor we have already chosen?
Yes, and this happens regularly. An honest evaluation sometimes confirms the choice and sometimes surfaces a risk worth renegotiating before signature.
03How long does a typical consulting engagement take?
Most reviews close within one to three weeks, depending on the size of the system or the number of options under comparison.
04What does a software consulting engagement cost?
It runs as a small, fixed engagement priced against system size and the number of options being weighed, agreed before the review starts.
05Will you tell us if our project is stalled because of our own team?
Yes, when the evidence points that way. The diagnosis is built to name the real cause, whether that is scope, estimation or the team itself.
06Do you build what you recommend afterward?
We can, but nothing obligates it. The recommendation is scoped to be usable by any team, including one you already have in place.
07Can you review an architecture decision our own team already made?
Yes, a second opinion on an existing decision is a common request, especially before a major investment builds further on top of it.
08Is the recommendation influenced by which vendor or tool is easiest for you to work with?
No. The recommendation is judged against your requirements and team, not against which tool happens to be convenient for us.