Outgrown Your Spreadsheets? How to Choose Between Buying, Extending, and Building

A spreadsheet never announces the day it becomes a production system. Five structural signals that a process has outgrown its tools, what the evidence on spreadsheet risk actually says, and a decision procedure that includes doing nothing.

A spreadsheet never announces the day it stops being a spreadsheet. There is no version where somebody renames it PRODUCTION_SYSTEM.xlsx. It just accumulates: a tab for exceptions, a column nobody can explain, a macro written by someone who left, a rule that lives in one person's head about which rows to ignore on a Monday. By the time anyone calls it a problem, three teams depend on it and nobody wants to be the person who breaks it.

The same thing happens with off-the-shelf software, more quietly. A tool that fitted two years ago now needs four integrations, two workarounds and a weekly export to do its job. What follows is a decision procedure for that moment: how to tell a tool you are using badly from a tool you have genuinely outgrown, what the evidence actually supports, and how to sequence the decision so you are not betting the year on being right.

The short version

• The test is structural, not emotional: a process has outgrown its tool when it needs concurrency, permissions, auditability, continuity or integration that the tool cannot express. Two or more at once is the threshold.
• The order is buy, then extend, then build. Extending — keeping the vendor's product as the system of record and building only the layer you need on top — is the option most teams skip and the one that most often fits.
• Doing nothing is a real option and nobody prices it. Reconciliation hours times loaded rate times fifty weeks, plus expected annual error cost, against the migration cost. If the first number is smaller, wait.
• The figure that decides a build is not the build: it is whether anyone owns the system afterwards. AI-assisted development has cut the cost of producing an internal tool much faster than the cost of maintaining one.
• Budget for the tail rather than the average. IT project overruns follow a power law — the mean is 27%, but one project in six overruns by around 200%.

The signal is not frustration

The honest test is not how annoying the current tool is. Frustration tracks familiarity more than fit, and the loudest complaint is rarely attached to the largest cost. The better test is structural: has the process acquired requirements the tool cannot express, no matter how carefully you use it?

Five conditions mark that line. One alone is usually survivable. Two or more at once is where the workarounds start costing more than the replacement would.

• Concurrency: more than one person needs to change the same data at the same time, and the current answer is a convention about who edits when rather than a mechanism that makes conflicts impossible.
• Permissions: different people need to see different things, and the current answer is separate copies of the file — which means there is no longer a single version of the truth.
• Auditability: someone needs to know who changed what and when, and the honest answer is that you would reconstruct it from email.
• Continuity: if one specific person were unavailable for two weeks, the process would degrade or stop, because the rules are in their head rather than in the system.
• Integration: the data has to reach another system, and it gets there because a human copies, exports or retypes it.

Notice what is not on that list: size, complexity, or how dated the tool looks. A ten-thousand-row spreadsheet that one person owns, nobody else edits and nothing else depends on is fine. It can stay. A two-hundred-row sheet that four people edit, that feeds invoicing, and that nobody can audit is a production system with no engineering behind it.

What the evidence actually says about spreadsheet risk

Almost every article on this topic opens with the claim that 94% of spreadsheets contain errors. It is worth knowing where that number comes from before you repeat it in a business case, because a CFO who checks will find what we found. It traces to a summary table compiled by Ray Panko at the University of Hawaii from field audits conducted between 1995 and 2004. His university page no longer resolves, his successor site was last updated in 2014 and no longer hosts the table, and several of the underlying audits were never published, so their methodology cannot be inspected. A 2023 literature review is now widely cited as a fresh source for the figure; it is a review, which means it inherited the number rather than measured it.

The better-evidenced picture measures something different. In a structured audit of operational spreadsheets from five organisations, researchers at Dartmouth's Tuck School of Business found errors in 0.8% to 1.8% of formula cells. That is not a smaller version of the 94% claim — it is a different unit. One counts workbooks containing at least one error; the other counts erroneous cells. A low per-cell rate and a high per-workbook rate are perfectly compatible, which is the part worth understanding.

The same study carries a finding that matters more than either rate. Of 381 potential errors the auditors flagged, 117 were confirmed as genuine by the spreadsheet's own developer — roughly a third. Read the other way, two thirds of what an outside reviewer flags turns out to be fine, so audits are noisy. But a third of them were real and had survived in a working sheet. Scale is what does the damage: a low per-cell rate across a large enough sheet makes at least one error near-certain.

It also is not hypothetical. In its 2025 statewide single audit, the Oregon Secretary of State documented a $45.1 million overstatement of deposit inflows and outflows at a state agency, caused by a formula error in the Excel workbook used to record monthly flows — missed by both the preparer and the reviewer. No money was lost. But an organisation with a preparer, a reviewer and a formal audit function still shipped a $45 million error out of a spreadsheet, which is worth remembering the next time process discipline is offered as the answer.

And buying a system does not, by itself, retire the spreadsheet. In the Association for Financial Professionals' 2025 FP&A benchmarking survey of 362 finance practitioners, 96% used spreadsheets for planning — while 71% also had dedicated planning software. The spreadsheet is usually not filling a gap in the product. It is filling a gap between products.

The number that matters more than your app count

If you go looking for how many applications a company like yours runs, you will find four answers, all published within eighteen months, differing by roughly 9x. They are not contradictory. They count different things.

Every article on this subject picks whichever number suits its argument. The gap between them is the more useful signal, and you can measure your own version of it this afternoon: ask IT how many applications the company runs, then ask finance how many software vendors it pays. Zylo's data explains why those two answers diverge — business units, not IT, control 81% of SaaS spend, according to its 2026 SaaS Management Index. If your finance-side number is three times your IT-side number, you have found something more actionable than any benchmark.

The count is a distraction anyway. MuleSoft's 2026 Connectivity Benchmark, based on 1,050 enterprise IT leaders, reports an average of 957 applications of which only 27% are integrated — down from 29% the year before against 897 applications. The stack grew and the connected share shrank. In the 2025 edition, IT teams reported spending 39% of their time designing, building and testing custom integrations. That is the real cost of app sprawl: not the licences, the glue between systems.

The human version of the same problem has been measured directly. Instrumenting 137 users across three Fortune 500 companies, researchers writing in Harvard Business Review found workers toggling between applications about 1,200 times a day, costing just under four hours a week — around 9% of working time — purely in reorientation. That study is from 2022, and it remains one of the few measurements of this taken by observation rather than by asking people to estimate.

Buy, extend, or build — in that order

The default order is buy, then extend, then build. Not because building is bad, but because building is the most expensive way to be right and the most expensive way to be wrong. Each step should be ruled out on evidence before you move to the next.

Most teams get this order wrong in one of two directions: buying a fourth tool to paper over the gap between the first three, or jumping to a custom build for something a mature product already does well. The first is cheaper to recover from.

Custom software vs off-the-shelf: what buying still gets you

Buy when the function is a commodity and time to value matters more than exact fit. Accounting, payroll, CRM, helpdesk, storefronts — these are solved, the vendors are competent, and your version of the problem is probably not special enough to justify building. The correct response to a 90% fit on a commodity process is usually to change the remaining 10% of your process, not to build software that preserves it.

Two questions make this concrete. If a competitor used exactly this software, would it cost you anything? If not, it is a commodity, and building your own is a way of spending money to arrive where a licence would have put you. And second: is the misfit in the product, or in how it was configured? A surprising amount of what gets described as outgrowing a tool is a tool that was set up once, by someone who has since left, and never revisited.

Extending: buy-like speed, with a ceiling

Extending is the option most teams skip, and it is often the right one. You keep the product as the system of record and build the specific layer you actually need on top of it — a portal, a workflow, a dashboard, an integration that reconciles two systems never designed to talk. This is the shape of a large share of the custom software work we do: not replacing the system of record, but building the operational layer around it that a vendor was never going to build for one customer.

The ceiling is real and worth naming before you start. Extension work depends on a surface someone else controls. If the vendor deprecates an endpoint, changes a data model, or moves a capability behind a higher tier, your extension is their release note.

• Good sign: the product exposes a documented, versioned API and your extension mostly reads and writes through it.
• Warning sign: the extension has to scrape the UI, poll because there are no webhooks, or keep a shadow copy of the vendor's data to work at all.
• Stop sign: you are extending three products at once to make one process work — which usually means the process, not the tooling, is what needs redesigning.

Internal tools: when building is the honest answer

Build when the process is specific to how you actually operate, when no mature product covers it, and when you will still want the thing in three years. That last clause does most of the work. Software has little salvage value; a system that is right for eighteen months and then irrelevant was an expensive way to solve a temporary problem.

The strongest case for building is rarely "the tools cannot do this." It is usually "the tools each do their part, and the coordination between them is where our time goes." Client portals, internal dashboards, review queues, approval and routing workflows — the recurring pattern is a business whose systems of record are individually fine and collectively unable to describe one piece of work end to end. That is also why the integration number above matters more than the app count.

If the answer to "where is this order right now?" is a person rather than a screen, you are paying for that answer every day, and the price appears on no invoice.

• Differentiation: the process affects customers or margins because you do it your way, not the standard way.
• Span: the requirement crosses several systems, and the integration is the product rather than an afterthought.
• Pace: the rules change faster than a vendor's release cycle, but not so fast that nothing can be specified.
• Ownership: someone will own it after launch. This is the condition most often assumed and most often absent.

Price the option of doing nothing

Almost every framework published on this topic terminates in a purchase or a build. That is not much of a coincidence: searching "build vs buy software" and "when to replace spreadsheets with custom software" in September 2026 returned a first page composed entirely of development agencies, SaaS-management vendors and integration platforms — parties who sell one of the outcomes. The academic literature does price the alternative, under the heading of real options, but it is not what a search returns. So: the option those results leave out is leaving it alone for another twelve months.

Doing nothing has a cost, and it is calculable. Take the people who touch the process, estimate the hours per week they spend reconciling, re-keying and chasing status, multiply by loaded hourly cost, and multiply by fifty. Then add an expected error cost: how often something goes wrong, and what the worst plausible single error would cost to detect and unwind. That second number is usually the larger one and almost never gets estimated, because it is uncomfortable.

Now compare it against a realistic build range. Vendor-quoted pricing clusters at roughly $30,000 to $100,000 for a departmental tool and $200,000 upward for an enterprise platform, according to GoodFirms' 2026 survey of software development firms — though note those are asking prices from vendors, not delivered costs. Clutch's review-derived average across completed projects is about $132,000 over roughly thirteen months, a figure that by construction excludes every project that failed badly enough that nobody wrote a review.

• Carrying cost: reconciliation hours per week x people x loaded rate x 50, plus expected annual error cost.
• Migration cost: data cleanup, dual running, retraining and the parallel period — the line item most build estimates omit entirely.
• Deferral value: what you learn in twelve months about how the process should work, which makes a later build cheaper and more likely to be right.

If the carrying cost is comfortably below the migration cost, the correct answer is to leave it alone and revisit in a year. That is a real outcome and it is more common than the search results suggest. We would rather write that in a discovery report than sell a build that does not pay for itself, and you should hold any vendor — including us — to producing that recommendation when the numbers say so.

Total cost of ownership: the part that decides the outcome

Vendors understate the cost of buying and agencies understate the cost of building. Both omissions are predictable, so budget for them directly. On the buy side, per-seat pricing scales with the thing you hope grows, integration glue gets written anyway by someone whose job is not writing integrations, and the exit cost stays invisible until you need it — check what a full data export actually contains before you depend on the tool, not after.

On the build side, the quoted number is the build. The number that decides the outcome is who owns it afterwards. And this is where the last two years have quietly changed the risk. AI-assisted development has cut the cost of producing an internal tool far faster than it has cut the cost of owning one. In Retool's 2026 survey — worth reading with the caveat that its 817 respondents are its own customers, so treat the rates as directional rather than representative — 60% said they had built tools outside IT oversight in the past year, 93% used LLMs to build, and only about half had shipped production software with AI. Maintenance burden already registered as a blocker for a quarter of them.

The failure mode is not that the tool gets built badly. It is that it gets built quickly, by someone whose real job is something else, and then that person changes team. Where the remaining work genuinely is judgement-heavy — classifying documents, extracting data from unstructured input — that is the point at which an AI consulting engagement is worth scoping, and the point before which it is not. Nobody writes the runbook because writing it was never part of the two afternoons it took. This is why documentation belongs in the contract as a listed deliverable rather than a good intention, and it is one of the things worth checking when choosing a development partner.

Budget for the tail, too. Analysing 1,471 IT projects in 2011, Bent Flyvbjerg and Alexander Budzier reported found an average cost overrun of 27% — but one project in six overran cost by around 200% and schedule by around 70%. Their later work across 5,392 projects showed the distribution is a power law, not a bell curve. The practical consequence: a 30% contingency calculated from the average is not conservative, because the average is not what hurts you. Sequencing is a better defence than contingency.

How to sequence it so you are not betting everything

The decision does not have to be made all at once, and it is usually better if it is not. This order gets you evidence before commitment, which is the only reliable defence against building the wrong thing well.

• Instrument first: measure where the time actually goes for two weeks. The bottleneck is frequently not the process that feels worst, but the quiet one everyone has stopped noticing.
• Write the requirements the tool cannot express: not a feature list, but the five structural conditions above mapped to your real process. If none apply, you have a configuration problem, which is far cheaper to fix.
• Price all four options honestly: buy, extend, build, and do nothing — each including migration and exit. If buying or extending clears the bar, take it.
• Scope the smallest build that removes the worst bottleneck: one workflow, not the platform. A first increment reaching production in weeks tells you more about feasibility than any amount of specification.
• Run it with real users before scoping the second thing: this is where you find out what the process documentation left out, and there is usually something.

The same staging applies to AI projects, for the same reason — the expensive failure is committing to a build before anyone has tested feasibility against real data. We have written separately about how to scope an AI engagement, and the stages are deliberately similar.

What to write down before you commit

Whichever way it goes, four things should exist in writing before money moves. They are cheap to produce now and expensive to reconstruct later.

• The decision and what would reverse it: "we are building because no vendor supports multi-party approvals" is revisitable when one ships. "The tools are frustrating" is not.
• Who owns the result: for a build, intellectual property assigned from the first commit, code in your repositories, infrastructure under your own cloud accounts — not a transfer promised at the end.
• The maintenance plan: a named owner and a budget. A system with no owner degrades whether it was bought or built.
• The exit path: for a licence, what a full export contains. For a build, whether ending the engagement is an access change or a migration project — a distinction we have written about at length in the context of choosing a vendor.

If you want a second opinion on which side of the line a specific process falls, that is what a paid discovery engagement is for: one to three weeks, a written architecture review, an estimate and a delivery plan you own regardless of whether the work continues. We run these across fintech, healthcare, logistics, retail and legal operations, usually alongside dedicated development teams or embedded engineers when a build does turn out to be the right answer.