When spreadsheets stop working: custom app, no-code tool or off-the-shelf?
Most operational spreadsheets start as a sensible shortcut. When one becomes the system the business runs on, the question isn’t which tool to buy, but what the work actually needs.
The short answer
Buy off-the-shelf software when the process is common and a mature product handles it. Use a no-code tool when one team needs structure fast and the rules are simple. Build a custom application when the workflow is specific to you, several systems must connect, and you’re prepared to own it. Map the work before choosing.
Spreadsheets are where a lot of operational software starts. Someone needs to track orders, jobs or approvals, a sheet is already open, and it works. Years later the same sheet has exception tabs, colour codes, notes copied in from email and one or two people who know which version is right.
At that point most teams start comparing products. This article suggests a different order: understand the work first, then compare four honest options against it, including the option of not replacing the sheet at all.
Signs the spreadsheet has become the system
A spreadsheet becomes a problem when it stops being a tool someone uses and becomes the system the business runs on. This is the situation we describe as a manual process that needs a proper system: work split between spreadsheets, inboxes and informal hand-offs. The signs are usually easy to observe:
- several people edit it every day and overwrite each other’s changes;
- updates arrive by email and are copied in by hand;
- exceptions live in extra tabs, colours or comments;
- some people shouldn’t see all of it, but the sheet can’t restrict that;
- nobody can say who changed what, or when;
- one or two people are the only ones who know how it really works.
None of this means spreadsheets are outdated. They are excellent for analysis, modelling and work that one person owns. The problem is using one as the system of record for a shared process with rules that have to hold.
Start with the work, not the tool
Before comparing products, map what the spreadsheet is really running. Do it with the people who do the work, using real examples, including the awkward ones. A working session with a whiteboard and a handful of real cases usually reveals more than a requirements document.
As you map it, mark each step as one of three kinds of work:
- Mechanical: copying, re-keying, lookups and checks that follow fixed rules.
- Preparation: reading untidy input, gathering information and getting a case ready for someone to act on.
- Decisions: the judgements someone is accountable for.
For each step, ask four questions: how often it happens, what a mistake costs and how quickly it is noticed, how easily the output can be checked, and who is accountable for it.
Then write down the rules that must always hold. “An order cannot be dispatched until its credit check is complete” is a rule, not a habit, and it belongs in the system rather than in someone’s memory. Finally, list the systems the process touches: accounting, CRM, email, perhaps a warehouse system.
The result of this exercise is what you compare options against. It is the same method we describe in Choosing what to automate, and it often shows that the thing to replace is smaller than it first looked.
Four options, honestly compared
Off-the-shelf software is built for a market and licensed to many customers: you adapt to it and the vendor runs it. Custom software is built around one organisation’s process: it fits more closely, and you own it and must run it. No-code tools sit between the two. And sometimes the best option is to keep the spreadsheet.
Keep the spreadsheet, but fix the process
If the pain comes from a handful of unwritten rules and the lack of a clear owner, a replacement may not be needed yet. Give the sheet one owner. Protect the ranges people shouldn’t edit. Put a form in front of it so input arrives in one shape rather than pasted from email. Write the exceptions down. This is the cheapest option, and it is sometimes enough.
Good fit when… one team uses it, the volume is modest and the problems are about discipline rather than capability.
Watch for… needs that a sheet can’t meet however well it is run: permissions by role, a reliable record of changes, or several teams writing to it at once.
Off-the-shelf software
For common processes such as accounting, payroll, a standard CRM or a helpdesk, a mature product has usually handled more edge cases than you will think of. It is faster to put into use, and the vendor runs, secures and updates it.
Good fit when… the process is much the same as other businesses in your industry and the product handles your awkward examples, not just the demo cases.
Watch for… workarounds where your process differs from the product’s, per-user pricing as the team grows, how you export your data and leave, and how deep the integrations really go.
No-code and database tools
Tools such as Airtable, Notion and Glide-style app builders can give one team structure quickly: proper records, views, simple forms and basic automations. Many can put an app on top of an existing spreadsheet, which is a quick way to turn a sheet into something closer to a web app. They suit simple rules, mostly reading and updating records, and early versions of a process that is still settling.
Good fit when… one team owns the process, the rules are simple and you want something working this month.
Watch for… permission granularity, audit history, complex rules, integrations and platform limits such as row and performance limits. Check the vendor’s current documentation rather than relying on someone’s memory of it. And if the spreadsheet stays underneath as the database, the app is only as reliable as the sheet.
A custom application
A custom application is built around your process: the workflow that is specific to you, the rules that must hold every time, the systems it has to connect and the data and access you need to control.
Good fit when… no product fits the important cases, several teams or outside parties work in it with different permissions, and the process matters enough to own.
Watch for… the upfront cost, the need to own and run the system afterwards, and the supplier you choose. Ask what documentation and handover you will receive, and whether your team could operate it without them.
Combining them
These options are not exclusive. Many teams keep a product for the standard part, such as accounting or CRM, and build or configure only the workflow that is specific to them and the integration around it. That is often smaller, and easier to own, than replacing everything.
How to choose: a decision framework
Take your process map and work through these questions in order. Each points towards an option.
- Is the process common in your industry, and does a mature product already handle the important cases? Start with off-the-shelf. Trial it against the real, awkward examples from your map.
- Is it one team, with simple rules, mostly reading and updating records, at modest volume? A no-code tool is likely enough, at least for now. If the problems are mainly about discipline, fixing the spreadsheet may be enough.
- Do several teams or outside parties write to it, with different permissions, and do some rules have to hold every time? Off-the-shelf if a product fits; otherwise custom.
- Does it have to connect to several systems you already run? Check integration depth before buying. If the connections are unusual, consider custom software or a custom integration layer around a product.
- How often does it happen, what does a mistake cost and how quickly is it noticed? Higher frequency, and costlier errors that are noticed later, justify more engineering.
- Who will run it after it is built? If nobody can own a custom system, prefer a product or a no-code tool, or commission custom work only with documentation and a handover your team can operate.
| If most answers point here… | Choose… | First step this month |
|---|---|---|
| One owner, simple rules, problems of discipline | Keep the spreadsheet and fix the process | Name an owner, protect ranges, add a form for input |
| A common process that a mature product handles | Off-the-shelf software | Trial two products against your awkward examples |
| One team, simple rules, needs structure quickly | A no-code tool | Move the data into the tool’s own tables and test permissions |
| A standard core with unusual connections | A product plus a custom integration | List each connection and what must pass across it |
| A specific workflow, firm rules, several systems and an owner | A custom application | Write down the process map, the rules and who will run it |
The parts everyone underestimates
The knowledge in one person’s head
When the business depends on one person who knows how everything works, no tool fixes that on its own. Mapping the process with that person is the first protection. Whichever option you choose, write the rules and exceptions down and put them in the system, so delivery doesn’t depend on one person’s memory.
Migration
Years of spreadsheet data rarely arrive in one consistent format. Decide what you actually need to bring across, clean it, map it to the new structure and validate it against the old records. Then decide how long, if at all, old and new run side by side, and when the spreadsheet stops being updated. This takes real effort; plan for it rather than assuming it will be quick.
Running it afterwards
Every option has an owner: a vendor, a no-code administrator, or your own team with documentation and runbooks. Choose with that owner in mind, because they will be living with the decision long after the project ends.
If custom is the right answer
If the framework points to a custom application, the way it is delivered matters as much as the code. We work in four stages: Frame, Design, Build and Transfer. Scoping starts from the process map and the rules that must hold, and we agree in writing what “done” means, what is in and out, and who will run the system. The build happens in reviewable increments, and the handover includes working software, documentation and runbooks your team can operate. Our stack is deliberately ordinary: TypeScript and Node.js, Go and PostgreSQL on Google Cloud. You’ll work directly with Veliora’s founder.
Questions
Are Excel spreadsheets outdated?
No. They’re excellent for analysis, modelling and one-person work. They become a problem when they’re the shared system of record for a process with rules, several editors and permissions they can’t enforce.
What’s the difference between custom and off-the-shelf software?
Off-the-shelf is built for a market and licensed to many customers; you adapt to it and the vendor runs it. Custom is built around one organisation’s process; it fits more closely, and you own and must run it.
Can we turn our spreadsheet into a web app?
Yes. No-code builders can put an app on top of a sheet quickly, which suits one team with simple rules. If several people write to it daily, need different permissions or a record of changes, move the data into a proper database.
What is key-person risk, and how does a new system help?
It’s when the business depends on knowledge or access held by one person. A new system helps only if the rules and exceptions are written down and enforced in it; start by mapping the process with that person.
How do we move years of spreadsheet data into a new system?
Decide what you actually need, clean and map it to the new structure, validate it against the old records, and agree when the spreadsheet stops being updated.
Not sure which option fits?
If your spreadsheet has become the system, tell us what is not working. If the answer turns out to be a product or a no-code tool, we’ll say so.
