Every month, a manager asks me "are we ready to leave Excel?". That's the wrong question.
The right one: how much is Excel already costing you per year, without you knowing? For many SMBs I work with, the answer is between €30,000 and €150,000 hidden in lost hours, re-entry errors, and risks brewing in the background.
Here's the full decision framework: the 5 signals Excel has become a risk, the back-of-the-envelope ROI calculation, the 3 possible exit paths, and the method that avoids breaking everything along the way.
The 5 signals Excel is no longer a tool — it's a risk
1. Several people edit the same file
Excel may have added co-editing, but the field reality is brutal: as soon as two staff members open the same file at the same time, someone loses their changes. One day or another, it'll be an invoice line, a negotiated price, or a critical lot number.
If your shared file has already triggered a conversation that starts with "okay, who overwrote my changes?", you're concerned.
2. Only one person knows how it works
The CFO goes on vacation, and the consolidation file becomes unreadable for everyone. Or worse: she resigns. You inherit a spreadsheet with 18 tabs, 400 nested formulas, three VBA macros no one has reviewed in five years.
It's a continuity risk. Not a theoretical risk — an operational risk that always materialises at the wrong time.
3. Formulas have piled up like geological layers
=IF(ISERROR(VLOOKUP(...)); 0; INDEX(...)) calls a cell that calls another sheet that calls a SUMPRODUCT over three columns filled by a macro. Modifying a row takes half a day. Auditing a cell requires an expedition.
If you're afraid to touch certain parts of the file, it has crossed its technical limit.
4. You have 4 versions: january, final, final2, reallyfinal
The file circulates by email, everyone has a local copy, no one knows which is the truth. You make a decision based on Tuesday's figures. Your colleague makes another based on Monday's. Both think they're right.
It's the sign you lack a single source of truth — exactly what a custom dashboard solves in one iteration.
5. You start copying chunks to other tools
The file has become so uncomfortable your teams export it elsewhere: to Notion, to Airtable, to a "cleaner" Google Sheets. Each one creates their satellite version. Data diverges. You compile by hand for the executive committee.
At this stage, Excel is no longer the work tool — it's a warehouse of disorder everyone is trying to bypass.
If you tick 2 signals out of 5, it's time to look at it seriously. If you tick 4 or 5, you're already in technical debt — it costs you money every month, and an incident is bound to happen.
How much Excel really costs you — the back-of-the-envelope calculation
The formula is simple. You don't need a consultant to set it up:
Annual hidden cost = Number of users × Hours/week × 45 weeks × Loaded hourly rate
The variables, one by one:
- Number of users: people who handle the file daily or at least weekly. Not those who open it twice a year.
- Hours/week: time spent entering, re-entering, correcting, consolidating, searching for a cell. Managers always underestimate — ask the users directly.
- 45 weeks: 52 - 5 weeks of vacation - 2 weeks of holidays/bridges. Adjust for your context.
- Loaded hourly rate: monthly gross salary × 12 × 1.45 (employer charges + benefits) divided by 1,607 hours (annual working time). For a manager at €45k gross annual, that's about €40/h.
Three concrete examples to position yourself:
| Scenario | Users | Hours/week | Hourly rate | Annual hidden cost |
|---|---|---|---|---|
| Small SMB 10 people, accounting & sales | 3 | 5 | €28 | €18,900 |
| SMB 50 people, multi-functions | 8 | 7 | €32 | €80,640 |
| Industrial SMB 80 people, in-house Excel ERP | 15 | 8 | €30 | €162,000 |
Now the counterpart: a custom business application, built on a clear scope, typically costs between €8,000 and €25,000 (using the ranges I publish on my pricing page). Amortised over 3 years, that's €2,700 to €8,300/year. Add hosting: €50 to €200/month depending on size.
The brutal observation: from the second scenario (SMB 50 people), Excel already costs 10 to 15 times what the application solving the problem would cost. On the third row, the ratio becomes absurd.
Do the calculation on your own file before reading on. If you come in below €10,000 per year, you can probably stay on Excel another year. Beyond that, you're paying invisible rent.
The 3 exit paths (and when to pick each)
Leaving Excel doesn't mean going custom. There are three paths, each with its strengths and ceiling.
Path A — Specialised SaaS
Your process is standard (sales CRM, invoicing, basic HR, accounting).
- Cost: €20 to €100/user/month, depending on the tool
- Lead time: setup 2 to 8 weeks
- Trap: 70 to 80% of the features you pay for will never be used. And the day your process leaves the box, the tool stops following.
When it's the right answer: your Excel file does exactly what any other SMB in the sector does. Classic sales pipeline, standard invoicing, basic HR.
Path B — No-code (Airtable, Notion, Retool, Baserow)
You have at least one "tinkerer" on the team able to maintain a configurable tool.
- Cost: €500 to €3,000/year in licences
- Lead time: a usable prototype in 1 to 3 weeks
- Trap: complexity ceiling. The day you want logic that leaves the grid (complex conditional workflow, specific API integration, proprietary business calculation), you're stuck. And the "tinkerer" becomes a single point of failure.
When it's the right answer: your needs are simple, you want to iterate fast, and you're comfortable with the idea of rebuilding in two years when you hit the ceiling.
Path C — Custom application
No market tool fits more than 70% of your process, or your business constraints are specific.
- Cost: €8,000 to €25,000 in development, then light hosting
- Lead time: 6 to 12 weeks typically
- Trap: ending up with a vendor who delivers in 9 months instead of 2, with an 80-page spec no one reads.
When it's the right answer: your process is your competitive advantage, you care about data sovereignty, and you want a tool that lasts 5 to 10 years without vendor dependency. That's the territory of my business application engagements.
Summary table
| Criterion | SaaS | No-code | Custom |
|---|---|---|---|
| Initial cost | Low | Low | High |
| 3-year cost | High (recurring) | Medium | Amortised |
| Adjustability to your process | ❌ limited | ⚠️ medium | ✅ total |
| Code/data ownership | ❌ | ⚠️ partial | ✅ |
| Evolution ceiling | Low | Medium | None |
| Lead time | 2-8 weeks | 1-3 weeks | 6-12 weeks |
For a more detailed angle on the SaaS vs custom decision with real figures, I refer you to the article I wrote on it — it complements this article on the SaaS side.
What systematically goes wrong when leaving Excel
The "all at once" migration
Friday evening, Excel closes forever. Monday morning, everyone discovers the new tool. Guaranteed catastrophe. Teams haven't had time to learn, edge cases haven't been tested, and within three days someone proposes "pulling the file out for a workaround".
The right approach: run both in parallel 2 to 4 weeks maximum, with a switchover date announced from the start. Not 6 months. Not "we'll see".
Leaving Excel "in parallel" forever
Reverse variant: you deploy the new tool but keep Excel "just in case". A year later, the team still uses Excel for 40% of tasks, and the new tool is shunned. You pay for both.
The right approach: set a firm Excel end date. Archive the file (read-only). Cut write access. Brutal but necessary.
Wanting to reproduce Excel identically
"Build me the same, but as an app." That's the worst request I receive. A good tool doesn't reproduce Excel — it replaces it with something else. If the application mimics the 18 tabs and 400 formulas, it inherits technical debt without Excel's advantages (flexibility, familiarity).
The right approach: start from uses (what decisions are made with this file?) rather than structure (what columns/formulas exist?). The final application will have 30% of Excel's features and cover 95% of real uses.
The method I apply — 4 steps, 8 to 14 weeks
Step 1 — Audit of real uses (1 week)
30-60 minute interviews with every user of the file (not the manager — the users). Precise questions: what are you looking for when you open it? What actions do you do? What frustrates you? What do you do outside the file because it doesn't allow it?
Generally, 70% of what's in the file is never used. The audit reveals what really matters.
Step 2 — Scoping must-have features (1 week)
From the audit, I list 15 to 25 actually used features. I prioritise them in 3 levels: must-have (no switchover without them), nice-to-have (phase 2), obsolete (drop them).
The manager validates the list. Not 80 pages of spec — a 15-line list with written agreement.
Step 3 — Build with weekly feedback (4-8 weeks)
I develop in one-week iterations. Every Friday, 20-minute demo with 1 or 2 key users. Adjustments the following week.
No "big bang" delivery. At the end of each week, a piece works and is tested by a real user.
Step 4 — Switchover + Excel archiving (1-2 weeks)
Double-run period: 2 to 3 weeks where Excel and the app run in parallel. Short user training (45-minute workshops, not 3 days). Excel end date announced, fixed.
Then cut. The Excel file goes to read-only archive. If within the next 4 weeks someone says "I'm missing such-and-such in the app", the audit was incomplete — I add it. Typically 2 to 5 minor adjustments.
Where to start
If you're hesitating to make the leap, the healthiest move is a 30-minute express audit. I take the slot here — it's free, no commitment, and you leave with:
- A quantified estimate of what Excel costs you per year
- An honest verdict: SaaS, no-code or custom, depending on your context
- An order-of-magnitude budget if the custom path makes sense
I never push custom when SaaS is enough. I regularly turn down engagements because the real answer is an off-the-shelf tool at €80/month. My price ranges are public — no opaque quotes, no runaway hourly rates.
What I care about is that you gain peace of mind, not that I bill an extra day.
To go further
- Related service: Custom application development
- Related articles: SaaS vs custom — the real math · When to go custom: 5 signals
