A multi-year technology roadmap commits budget, people, and architecture long before results appear, yet it often rests on consultant recommendations nobody has independently tested. Before you sign off, work through a review sequence that verifies the evidence behind each recommendation and challenges every proposed initiative on its assumptions, costs, risks, and fit with your business priorities.
A software consultation arrives as a polished document: a three-year roadmap and a number at the bottom that someone expects you to approve. The analysis reads well. The diagrams are clean. And the recommendations carry an air of settled fact, even though almost every one rests on interviews and assumptions nobody wrote down.
That gap is where the money goes. McKinsey and the University of Oxford studied 5,400 IT projects and found that the large ones, with budgets above $15 million, ran 45 percent over budget and delivered 56 percent less value than predicted. The study dates from 2012, and those budgets far exceed what a seed-to-Series B team can handle, but the pattern isn't limited to large projects: money gets committed before anyone has tested the plan. Your job before approval is to find out which parts of it are true.
At founder scale, the same gap hits harder. A recommendation to rebuild the billing service or split the monolith can swallow a quarter of your engineering capacity and a meaningful share of your runway, with no second budget to absorb the miss. That is why the review below is built for a small team to run in a few working sessions.
Start by renaming the thing in front of you. A software consultation is a set of hypotheses about your systems and a proposal for what to do about them, and each hypothesis has to survive contact with your own data before it earns funding. Treat the document as testable, and the review becomes straightforward.
Then settle three governance questions in writing before anyone opens the appendix. Who reviews the technical evidence, and who signs the check? Who owns the result once the consultants have left? The first two are rarely the same person, and when the distinction stays blurry, the review collapses into a presentation. In a startup, the signature is usually the CEO’s, while the technical review falls to a CTO or lead engineer who is also shipping product. Decide who gets the time to do the review properly, and who can overrule them.
Define the scope of the current decision too. Approving a discovery phase isn't approving a replacement program, and a roadmap that bundles both into one signature asks you to commit to year three based on year one's software requirements-gathering analysis. Separate them now, and the rest of the review has something to bite on.
Name the outcome and the number that proves it. “Reduce order-to-cash cycle time from 11 days to 6” survives scrutiny in a way that “modernize the finance stack” never will. The same holds at startup scale: “cut customer onboarding from two weeks to three days” can be tested, and “scale the platform” cannot.
Then set down the facts the recommendations will be measured against: the current architecture and how much delivery capacity your teams have after keeping the lights on. Gartner's survey of more than 3,100 technology executives found that only 48% of digital initiatives meet or exceed their business outcome targets, and a vague baseline is how a program ends up in that half without anyone noticing.
Now compare your baseline against the consultant's stated starting point. Mismatches matter more than they look. If their software requirements gathering assumed four of your six engineers were free for the migration, and in practice one is on call and another is the only person who understands billing, every date in the roadmap is wrong, and so is every cost built on those dates.
Every major recommendation in the software consultation should trace back to at least two independent sources. One source is an anecdote. Two sources that agree is a finding, and two that disagree is the most useful thing in the document, because it tells you where the real uncertainty sits.
As you trace, sort each supporting statement into one of four buckets. Separate what was observed directly or said by a stakeholder from what the consultant inferred or carried forward as an unverified assumption. Most decks blend all four into the same confident voice. Pulling them apart takes an afternoon and changes how the roadmap reads.
Claims about the codebase are the easiest to check and the most frequently waved through. Ask which repositories were examined and which were described to the team rather than read. A software consultation that recommends replacing a system its authors never cloned is making an argument from reputation.
Check the integration surface yourself. Count the consumers of each interface and trace the data flows that cross system boundaries. McKinsey’s survey of 50 CIOs put tech debt at 20 to 40 percent of the value of their technology estate, so a debt claim is credible in principle. A debt claim without a named module and a measured cost is not. “The billing service adds three days to every pricing change” can be checked, and “the codebase is full of legacy” cannot.
Security controls deserve their own pass, because they're the easiest place to generate alarm without evidence. A finding should name the control and the exposure. If the report says the authentication layer is outdated, ask what an attacker does with that, and what compensating controls already sit in front of it.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Your monitoring stack already knows whether the problems described in the software consultation report are real. Whether that is Datadog, Grafana, or your cloud provider’s default dashboards, pull the latency distributions and the error rates for the systems named in the assessment. Then check whether the shape of the data matches the urgency in the prose.
This is where scale claims collapse or harden. A report describing a capacity crisis should correspond to utilization curves heading somewhere unpleasant, and if the curves are flat, the crisis is a forecast rather than a fact. Cost claims deserve the same treatment, especially in cloud estates, where Flexera's 2026 survey put wasted spend at 29% of cloud spend on infrastructure and platform services.
Delivery telemetry tells you something the consultant rarely has access to. DORA's 2024 research put elite teams at a change failure rate of 5% with recovery under an hour, so if your own numbers are nowhere near that, the roadmap needs to account for it. A plan that assumes delivery performance you don't have is a plan that slips in month four.
Risk language is cheap. Incident records are not. For each risk the software consultation report cites, go to your incident log, which at an early-stage company may be a Slack channel, a postmortem folder, or a PagerDuty history, and ask how many times it has actually materialized and what it cost the business when it did.
Half the time you'll find the risk is real and underweighted. The other half you'll find a mitigation that was quietly put in place eighteen months ago, which nobody mentioned during the interviews. Uptime Institute's 2024 survey found that 54% of respondents had a most recent significant outage that cost more than $100,000, which gives you a reasonable way to price the risks that do have a history behind them.
Systems are used in ways no architecture diagram records. Before accepting a recommendation that changes how people work, watch them work. The spreadsheet that sits between your CRM and your billing system is a requirement in disguise, and replacing either one without absorbing that spreadsheet moves the problem rather than solving it.
Workarounds also predict adoption. Gartner estimated that 41% of employees acquired, modified, or created technology outside IT’s visibility in 2022. At a startup, that looks like the support lead’s Airtable base or the sales team’s chain of Zaps. Ask what those employees are routing around, because whatever it is will still be there the day after go-live unless the roadmap names it.
Now go back through the interview list. Count how many people were spoken to and which groups were skipped. Software requirements gathering that covered the founders and two senior engineers, but no support staff, salespeople, or customers, produces a roadmap that solves the leadership team’s picture of the problem. At your stage, the frontline is whoever answers support tickets, runs demos, and talks to your first dozen customers.
Look for the conflicts rather than the consensus. Real organizations disagree about priorities, and a requirements document in which everyone agrees is one where disagreement was smoothed away during synthesis. PMI's 2014 research found that 47% of unsuccessful projects failed to meet their goals because of inaccurate requirements management, which makes software requirements gathering the cheapest section of the review to get right.
Finally, check traceability. Each requirement should point backward to who asked for it and forward to the initiative that delivers it. Where that chain breaks, you've found something that entered the document without an owner, and unowned requirements are how scope grows after the budget is fixed.
For every recommendation large enough to need funding, require an architecture decision record. The format Michael Nygard proposed in 2011 and Thoughtworks placed in Adopt on its technology radar captures the context and the decision on a single page. The UK Government Digital Service uses the same structure for recording architecture decisions across its services. At your scale, this is a page in the repository or a Notion doc, not a committee artifact.
Extend it with two sections the standard template leaves out. List the options considered and rejected, with the reason each was dropped. Then list the assumptions the decision depends on, which is where the software requirements gathering work pays off a second time, because an assumption traced to a named stakeholder can be checked with a phone call.
Replacement should never be the only option on the table. Martin Fowler's strangler fig pattern describes building the new system around the edges of the old one and retiring it piece by piece, which changes the risk profile of the entire program. If the software consultation report dismisses incremental approaches, ask for the analysis that ruled them out rather than the sentence that announced it.
Then ask the question that separates a defensible recommendation from a preference: what new evidence would change this? A consultant who can answer is reasoning. One who can't is advocating.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Independence is a structural question, and the practical version of it is about money. Ask how the adviser is paid, and weigh the advice accordingly. A firm that earns implementation revenue, reseller margin, or partner referrals on the technologies it recommends has a reason to find that the answer is a build or a purchase. A firm paid a flat fee for the assessment alone has less of one. Neither arrangement is disqualifying, but each changes how much weight a recommendation deserves. Ask who the firm partners with and what share of its revenue comes from implementing the technologies it recommends. A firm that cannot answer plainly has told you something already.
The incentive shows up in what’s missing. Scan the options analysis for the alternatives that never appear: the competing platform and the configuration change that solves 60% of the problem for 5% of the cost. In The Big Con, Mariana Mazzucato and Rosie Collington argue that heavy reliance on consultancies can hollow out the capability of the organizations that hire them. That is a reason to ask what the adviser stands to gain from each option, and not only whether the option is sound.
Then look at what happens to the relationship after approval. If the firm that wrote the recommendation is also bidding to deliver it, weigh the recommendation accordingly and get a second opinion on any choice where the consultant’s revenue moves with your decision. At seed to Series B, that can be a fractional CTO or a senior engineer from your network reviewing the one recommendation that drives most of the spend.
A roadmap item is a commitment, and a commitment that can't be described in operational terms isn't ready for funding. Before any initiative enters the approved plan, require it to specify:
The named owner, with the authority and the calendar to run it
What it depends on, and what depends on it
Which measured risk it reduces, and by how much
The delivery capacity it consumes, counted in people your organization actually has
Implementation work and adoption work, budgeted separately
The recurring cost that outlives the project
The measurable result that defines success, and the gate where that result gets checked
Adoption work is the line most often missing. Building the system and getting people to use it are different programs with different costs, and roadmaps that fund only the first are how a technically successful migration produces no business change. Every one of these items also feeds the technical feasibility assessment that comes next.
A technical feasibility assessment answers whether the proposed thing can be built here, by these people, inside these constraints. Architecture fit comes first: does the target design work with the systems that will remain, or does it assume a cleaner environment than the one you operate? Integration complexity follows, counted in interfaces and in the teams that own them.
Skills are where estimates quietly break. Birmingham City Council moved its IT services in-house in 2019 with 300-plus transferred staff who were not Oracle specialists, and building that capability internally proved very challenging according to Grant Thornton's later report. The same gap exists at startup scale. A plan that has a six-person team running a Kubernetes migration alongside the product roadmap, when nobody on it has operated a cluster in production, is resting on a capability you do not have.
Data migration deserves its own technical feasibility assessment rather than a line in the plan. So does operational readiness: monitoring and the rollback path. Only once the technical feasibility assessment has covered all of this does a schedule or a budget mean anything, because effort estimates produced before feasibility work are guesses wearing a spreadsheet.
Gates convert a roadmap into a sequence of smaller decisions you can still reverse. Each one needs four things specified in advance:
The evidence required to pass, named and measurable
The person accountable for the pass or fail decision
The spending limit that applies until the gate is cleared
The exit criteria that show the phase delivered what it promised
Birmingham's Oracle implementation shows what happens when the gate exists, but the evidence doesn't reach it. Grant Thornton's 2025 report concluded that if information on testing quality had been presented more clearly to the steering committee, "it is unlikely that the program would have approved the decision to go live." The project's cost has been tracked from an original £19m toward an estimated £216.5m by April 2026.
At seed to Series B, a gate does not need a committee. It can be a 30-minute review at the end of each phase with the CEO, the CTO, and one outside adviser or board member, with the four items above written on a single page beforehand. What matters is that the evidence reaches the people who decide, which is where Birmingham’s did not.
Keep the gates close together early on, when uncertainty is highest, and the technical feasibility assessment has the least data behind it. Space them out later, once the first delivery has told you how accurate your estimates are.
Order matters as much as content. For each initiative, ask what must be finished or learned before the next one starts, and whether the roadmap's sequence reflects that or just reflects the order the problems were discovered.
Put uncertainty reduction first. The work that tells you whether the hard thing is possible should happen before the work that assumes it is, which means a six-week spike on the integration nobody understands outranks a twelve-month platform build in the queue. Flyvbjerg and Budzier's analysis of 1,471 IT projects found that one in six projects was a black swan with an average 200% cost overrun, and those outliers cluster in long commitments made before the unknowns were resolved.
Then check the sequence against capacity. Standish Group's data has consistently shown that project size predicts outcome, with only 6% of grand projects succeeding against 61% of small ones. Reordering toward smaller, independently valuable pieces is the cheapest risk reduction available to you.
The last test is reversibility. At each point in the sequence, ask what happens if the program stops there. A good roadmap leaves working systems and retained value at every pause point, and a bad one leaves a half-migrated estate that costs more to run than the one you started with.
Four outcomes, and you have to pick one. Approve, if the evidence holds and the sequence is sound. Revise, if the direction is right and specific initiatives need rework. Validate first, if the core recommendation depends on an assumption you can test in weeks rather than quarters. Reject if the software consultation can't support its central claim.
Whichever you choose, write down why, in a document that survives the people who wrote it. Record the conditions attached to approval and the date you'll look at this again. Two years from now, that record is the only thing standing between your successor and a repeat of the same analysis.
Good roadmaps fail because nobody tested them while testing was still cheap. If your team wants a second opinion on a software consultation before funding is committed, reach out to us, and we’ll work through the evidence with you.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Request a written decision brief that states the problem, expected result, evidence supporting the first phase, estimated cost, and stop conditions. The software consultation should also identify who owns the work and what information the phase must produce. This keeps early funding limited to a testable decision instead of an open-ended program.
Compare the estimate with named people, their available hours, and the operational work they must continue. Ask the team to review the estimate without the consultant present, then record disagreements and missing tasks. If the schedule depends on skills or time that aren't available, revise the sequence before approving the initiative.
Implementation pays for building, configuring, or moving the system. Adoption pays for training, process changes, support, and time away from normal work. Separating these budgets shows whether the expected business result depends on behavior change. The client can then track technical completion and actual use as different approval conditions.
Seek an independent review when the adviser can earn implementation revenue, the recommendation removes competing options, or the decision commits substantial future spending. Give the reviewer the evidence pack, assumptions, and rejected alternatives rather than only the presentation. A useful review tests the reasoning and checks whether the recommendation fits your operating constraints.
Pause the related spending and record which evidence was missing or failed. The owner should propose one of three actions: correct the work and retest it, narrow the scope, or stop the initiative. Set a new decision date and preserve completed work so the organization can reuse valid findings instead of restarting the review.
Tell us about your idea. 24-hour response. NDA-friendly.
