Business softwareSMEsCustom softwareMethodPrototype
Replacing Excel spreadsheets with a custom business application
7 min read
Replace an Excel spreadsheet with a custom business application when it has become a shared production tool: several people edit it, versions diverge, only one person can maintain the formulas, or an error has already cost money. Keep Excel for analysis, move data entry and business rules into the application, and migrate one process at a time.
Almost every business application starts life as a spreadsheet. That is not a failure: Excel did exactly what it was asked to do. But there comes a point where the file carries more risk than value. Here is how to recognise that point, which options you have, and how to move without losing what the spreadsheet did well.
Excel is not the problem
A spreadsheet is a remarkable tool for calculating, exploring data, preparing an analysis or testing an idea. It is fast to build, everyone knows how to use it, and it needs nobody's permission.
The problem starts when the same file changes role: it no longer serves to analyse, it serves to produce. Orders are entered in it, jobs are planned in it, stock is tracked in it, bonuses are calculated in it. It becomes the memory of a shared process, a role it was never designed for: no reliable input control, no permissions by role, no change history, no safeguard against a deleted row.
The signals that do not lie
| Signal | The risk behind it | What an application does instead |
|---|---|---|
| The file is locked when you need it | Copies are made, then diverge | Everyone works on the same data at the same time |
| Several versions circulate by email | Nobody knows which one is authoritative | One source of truth, always current |
| One person maintains the formulas | The process depends on one person's availability | Rules are written into the application and documented |
| An error has already cost money | A formula overwritten, a range that misses the last rows | Rules are enforced at input, not checked afterwards |
| Data is re-typed into another system | Lost time, and a new chance of error each time | Connections to the ERP, CRM or accounting system |
| Field teams take notes on paper | Information arrives late, or not at all | Entry from a phone, on site |
One signal can be handled with some discipline. When three or four add up, the spreadsheet has become an application, just without an application's protections.
Spreadsheets have hard limits too
Excel's own limits are generous, but they exist: a worksheet holds at most 1,048,576 rows and 16,384 columns, according to Microsoft's specifications. Older file formats hold far less, and that difference once made the news. In the autumn of 2020, nearly 16,000 positive COVID-19 test results were left out of England's daily figures between 25 September and 2 October, because data was loaded into templates in the older .xls format, limited to about 65,000 rows, as The Conversation reported.
The lesson is not that Excel is unreliable. It is that a spreadsheet does not warn you when a process outgrows it: it simply stops counting.
Four ways out, each with its place
| Option | Fits when | Watch out for |
|---|---|---|
| A better-structured spreadsheet | One owner, little sharing, simple rules | The same limits come back as soon as the team grows |
| A no-code tool | Simple process, small team, few integrations | Pricing per user, limits on complex rules, dependence on the platform |
| Off-the-shelf software | Your process is standard in your industry | Paying for unused features, adapting your way of working to the tool |
| A custom application | Specific rules, several roles, connections to your other systems | Needs scoping, and a budget for life after launch |
There is no shame in starting with a no-code tool, and no reason to build custom software for a process an off-the-shelf product already handles well. The custom route earns its place when your rules are what makes your business different. We compare that decision in more depth, in French, in our article on custom versus off-the-shelf software.
Your spreadsheet is already your best specification
This is the point most often overlooked: a spreadsheet that has run for years is a specification of rare precision. Its columns describe the data. Its formulas describe the calculation rules. Its tabs describe the steps of the process. Its conditional formatting describes the alerts the team needs.
There is no need to rewrite everything into a fifty-page document before starting. The file, plus a conversation with the people who use it every day, is enough to produce a prototype: the screens of the future application, with your real columns and your real cases, that you can validate or correct before any commitment.
The conversation matters as much as the file. It reveals what the spreadsheet does not say: the workarounds, the cells coloured by hand, the "notes" column where a business rule is actually hiding.
Migrating without disrupting the business
- Start with the most painful process, not the whole file. A small scope used for real beats a complete replacement that never arrives.
- Prepare the data migration with someone from the business. Duplicates, inconsistent formats, merged cells and free-text comments must be resolved before import. This work weighs on the budget, as explained in our article on the cost of a custom business application.
- Run both in parallel for a few weeks, while teams find their bearings and the last gaps are fixed.
- Connect rather than re-type. If the data then goes into an ERP or an accounting system, plan the connection from the start.
- Keep Excel for what it does well. An export or a read-only connection lets teams keep analysing data in a spreadsheet, without ever modifying the reference again.
An example from our own software
Izi-Devis, the quoting and invoicing application for building tradespeople that we publish and run ourselves, replaces exactly this kind of homemade document. A quote follows a lifecycle that a spreadsheet does not enforce: it is drafted, finalised with its own number, sent, then turned into an invoice without anything being re-typed. Those rules live in the application, not in anyone's memory, which is the whole point of leaving the spreadsheet behind.
Where to start
Gather the file as it is, with its tabs and macros, and write a few lines on what costs you time or worries you. That is enough for a first conversation.
At LPR Studio, that first conversation leads to a free visual prototype, presented in a video call within 5 working days. You see your spreadsheet become an application before deciding anything, and then you choose the model that suits you: fixed price, subscription without paying for development, or SaaS. How to contract it is covered in fixed price vs time and materials.