A spreadsheet, an off-the-shelf ERP and custom software are not competing for the same spot: they sit in different layers of the same operation, and almost every healthy company runs all three at once. The expensive mistake is not picking the wrong one, it is changing layers when you did not have to: at a five-location gym chain the off-the-shelf ERP stayed as the source of every sale, and the custom system simply started reading from it every five minutes. The spreadsheet, in turn, stops working for three objective reasons, and none of them is size.
Why "spreadsheet, ERP or custom software" is the wrong question#
The question almost always arrives in the same shape: the company grew, the spreadsheet is bursting, and somebody has to choose between buying an off-the-shelf ERP and having custom software built. Phrased that way, it already carries a mistake: it treats the three options as steps on a ladder, where climbing one means abandoning the last.
That is not how an operation works. A spreadsheet, an off-the-shelf ERP and custom software sit in different layers, and almost every healthy company we serve runs all three at once. The ERP holds what is mandatory and standardised. Custom software covers the process that is the house's competitive advantage, the one no vendor sells ready made because it only exists there. And the spreadsheet remains the best tool in the world for a one person calculation, done once, that never becomes a process.
The useful question, then, is not "which of the three". It is "which layer does each one occupy here, and where is the gap". People who answer that version of the question make fewer mistakes and spend less.
How far a spreadsheet takes you, and the day it becomes a risk#
A spreadsheet works as long as three conditions hold at the same time: one person edits the file at a time, a typo is noticed and fixed the same day, and no sensitive personal data travels in it. While all three hold, building software is waste, and the honest answer from a vendor is to say so.
The problem is that a spreadsheet never announces that it stopped working. It still opens. What changes is the hidden cost around it.
At Cleantec, a reference in industrial sanitation and food safety, the control of cleaning, chemical consumption and microbiological analysis inside food plants lived in Excel, with one spreadsheet per client, filled in by hand. The file opened normally. What it could not do was control product surplus precisely or talk to the stock inside the plant, so waste was invisible and replenishment happened in the dark. For an operation that underpins the food safety audit of an exporter selling to more than seventy countries, that stopped being inefficiency and became risk. Today the same work lives in a single dashboard across four GTFoods plants, with more than 460 microbiological analyses tracked per month and consumption followed product by product, forecast against actual. The process detail is in the Cleantec case study.
There is one line harder than all the others, and it has nothing to do with volume. It is sensitive personal data. In Sistema Cuidar, the psychosocial risk assessment instrument ran on Google Forms, and the assessed companies simply refused it: identifiable worker mental health data, in a generic form and a shared spreadsheet, does not get past anybody's legal team. Brazil's data protection law treats health data as a special category, and a shared spreadsheet has no access control, no record of who saw what, and no way to prove anonymity. When the data is of that kind, the spreadsheet is not a stage of growth, it is an exposure.
What an off-the-shelf ERP solves better than any custom system#
There is a family of processes where buying beats building, and it has one trait in common: these are processes defined outside your company.
Tax filing, payroll, statutory reporting and accounting change by government decision, not by yours. Building that from scratch means taking on maintenance that never ends and that creates no advantage, because the correct result is identical to your competitor's. An off-the-shelf ERP spreads that cost across thousands of companies and keeps a team dedicated to following regulation. It is a good trade, and recommending the opposite would be selling hours.
The same applies, with less force, to processes that are completely standardised within an industry. If your way of doing it is the same as your neighbour's, a ready made product exists, and the ready made product gets in faster.
What an off-the-shelf ERP does not solve is what comes after the data is inside it: the reading only your operation does, the rule that is yours, the screen your team needs and the vendor will never prioritise because it serves one client.
The most expensive mistake is replacing the ERP when reading from it was enough#
Of every decision in this family, the one that costs most is replacing a working off-the-shelf ERP because a screen is missing. And it is a common decision, because frustration with the vendor is real and gets mistaken for a system problem.
Fitness Academia runs five locations between Chapecó and Cunha Porã, and sales data already lived in NextFit, the off-the-shelf ERP for that industry. What sat outside was the commercial target: rebuilt by hand in a parallel spreadsheet, with a different criterion at each location, which made the numbers incomparable with each other. The sales consultant, who most needs to know how much is left to hit target, had no screen at all, and the manager opened five files to see the chain.
None of that required replacing the ERP. NextFit is still the source of every sale, and the system we built reads from it every five minutes and turns that into a single reading: the chain, the location and each consultant's contribution. The ERP stayed in its layer, the custom system came in on the layer above, and the result is in the Fitness Academia case study.
The same logic applies to a legacy system of your own, and we measured it in our own operation: of the nine systems that already existed when we arrived, we replaced two and five are still under maintenance. Old, ugly or slow is not a reason to replace, and the full criterion is in the article on when a legacy system needs replacing. When the decision is to integrate instead of replace, what changes in the project is in integrating with the ERP your operation already runs.
What only custom software solves#
Three situations have no off-the-shelf answer, and recognising them early saves months.
The first is the process that is your advantage. If the way your company does that thing is the reason a client picks you, no ready made product exists for it, because a ready made product is built for the market average and your advantage is precisely the deviation from the average.
The second is volume or format a generic tool cannot hold. In the sheep genomic evaluation platform we built for DNA Genética do Brasil, each animal is genotyped on an 80,000 marker chip, and the laboratory returns a 4.3 GB file with around 59 million rows. Microsoft documents that a single Excel worksheet holds a little over one million rows, so that file breaks the limit dozens of times over. This is not a discipline problem: it is impossible by construction. What the platform does with that file is in the SheepGen case study.
The third is the rule that changes by external event and has to be maintained by whoever operates, not by whoever programs. A rule of that nature registered as data becomes your team's autonomy; the same rule written inside an off-the-shelf product becomes a feature request in a queue that is not yours.
The criterion, in one table#
| The question | Spreadsheet | Off-the-shelf ERP | Custom software |
|---|---|---|---|
| Who defines how the process works | you, changing it whenever | the law or the vendor | you, and it becomes software |
| How many people work at once | one at a time | many, with profiles | many, with profiles and your rules |
| The process is the same as a competitor's | irrelevant | yes, and that is good | no, and that is your edge |
| Sensitive personal data | must not be there | yes, with controls | yes, with controls by design |
| What happens when volume doubles | breaks or crawls | stays the same | stays the same, it was sized |
| Time to be live | today | weeks of rollout | weeks to months, by scope |
| What you give up | traceability and access control | the rule that is only yours | what comes ready made |
A quick read of the table: no column wins at everything. That is why the answer almost always combines two of them.
What each step costs, in hours#
Price depends on scope, and a price range thrown on the internet helps nobody decide. An effort range does, because it shows the order of magnitude of each step. Across the 18 cost estimates we have on record, effort falls out like this:
| Step | Observed range | What usually fits in it |
|---|---|---|
| One process leaving the spreadsheet | 74 to 122 hours | one module, one user profile, one simple integration |
| An operational system | 247 to 656 hours | four to eight modules, two or three profiles, integration with what exists |
| A platform | from 1,250 hours | several products or several external profiles, rules maintained by the client |
Two observations worth more than the numbers. The first is that what pushes an estimate up is almost never the technology, it is how much rule has to be discovered before it can become software: a process nobody has written down yet costs more than a documented one. The second is that the bottom range is real, and it is usually the one worth starting from.
Three signs a spreadsheet already costs more than it looks#
It is not company size, and it is not row count. It is three operational signs, and any one of them is enough.
The first is the question "which one is the good version". When two people edit different copies and nobody knows which one counts, the file stopped being a source of truth and became an opinion.
The second is the same number typed twice. When somebody copies from a system into a spreadsheet to produce a reading, the work is not the reading, it is the typing, and typing goes wrong on its own.
The third is the audit. When someone outside, a client, an auditor or a regulation, can ask for proof of what was done, a spreadsheet does not prove: it records neither who changed what, nor when.
Frequently asked questions#
Is it worth replacing an off-the-shelf ERP with custom software?#
Most of the time no, and this is the most expensive mistake in this decision. If the ERP already holds the right data and the pain is in what it does not show, replacing the whole system means paying again for everything that already works in order to fix the one missing piece. At a five-location gym chain we serve, sales already lived in the off-the-shelf ERP and what sat in the spreadsheet was the commercial target, rebuilt by hand with a different criterion at each location. The ERP stayed where it was, and the custom system started reading from it every five minutes. Replacement is justified when the data itself is locked in, when nobody can change the system any more, or when the operation has already built a workaround outside it.
How long can a spreadsheet keep working?#
As long as three things are true at the same time: one person edits the file at a time, a typo is noticed and fixed the same day, and no sensitive personal data travels in it. While all three hold, the spreadsheet is the right answer and building software is waste. The bill arrives when two people start editing different copies, when nobody can say which version is the good one, or when the data in that file has to answer to an audit, a regulation or a client.
How much does custom software cost?#
Across the 18 estimates we have on record, effort falls into three steps. Taking one specific process out of the spreadsheet, with a single user profile and one simple integration, landed between 74 and 122 hours. An operational system, with four to eight modules, two or three profiles and integration with what already exists, landed between 247 and 656 hours. A platform with several products or several external profiles goes past 1,250 hours. What moves that number is rarely the technology: it is how much of the rule has to be discovered before it can become software.
Can we start small and grow later?#
You can, and it is usually the best way to start. The condition is that the slice has to be a whole process and not half a process: if the user still has to finish the job in the spreadsheet after going through the system, the system replaced nothing and only added a step. Starting small also gives you information no meeting gives, which is watching the team actually use it before deciding on the second module.
What if I already have both an ERP and spreadsheets?#
That is the most common state of all, and it is a ready-made diagnosis. A spreadsheet that survives next to an ERP shows exactly where the ERP does not reach, because nobody keeps manual work for fun. List every living spreadsheet and answer, for each one, where the data feeding it comes from. When the data is already in the ERP and the spreadsheet only rearranges it, the path is reading, not replacement. When the data is born in the spreadsheet and exists nowhere else, that is the process asking for its own system.
Sources#
- Microsoft, Excel specifications and limits, for the row limit per worksheet.
- Brazilian General Data Protection Law (Law 13.709/2018), for the treatment of sensitive personal data.
Next step#
If your operation today is an ERP plus spreadsheets, the list of living spreadsheets is the best starting point there is, and it takes less than an hour to make. One question per spreadsheet: where does the data feeding it come from. That inventory is what separates what needs reading from what needs its own system, and it is where we start a custom software project.