A spreadsheet should become a small custom app when several people edit it at once, mistakes in it cost real money, it needs different permissions for different people, or staff spend time copying data between it and other systems. If only one or two people use it, the data fits on one sheet and errors are cheap to fix, keep the spreadsheet. The move to an app is worth it when the spreadsheet has quietly become a database, a workflow and a reporting tool all at once, and it is no longer reliable at any of them.
What are the signs a spreadsheet has outgrown itself?
- People are overwriting each other. Two staff edit the same row, or someone sorts one column and not the others.
- There are several versions. “Jobs FINAL v3 (Sam’s copy)” exists, and nobody is sure which is current.
- Formulas break quietly. A pasted row breaks a lookup, and totals are wrong for weeks before anyone notices.
- Everyone sees everything. Contractors can see pricing, or customers’ personal details sit in a file shared with a whole team.
- Data is retyped. Website enquiries are copied in by hand, then copied out again into invoices, emails or a booking system.
- Only one person understands it. The macros, hidden tabs and colour codes live in one head.
- It is slow or huge. The file takes ages to open, or you are splitting it by year to keep it usable.
- You need a history. You cannot easily tell who changed a price or a status, or when.
One or two of these can be managed. Several at once usually means the spreadsheet is costing more in staff time and errors than an app would cost to build.
What should you try before building an app?
A custom app is not always the next step. Check these first:
- Tidy the spreadsheet. Data validation, protected ranges, one row per record and a separate tab for settings fix a surprising amount.
- Use a form for data entry. Google Forms or Microsoft Forms feeding the sheet stops people editing rows they should not touch.
- Look for an off-the-shelf tool. If the spreadsheet is really a CRM, a job management system or a booking calendar, a mainstream product may do it better and cheaper.
- Try a database-style tool. Airtable, Smartsheet and similar sit between a spreadsheet and an app, with forms, views and basic permissions. Pricing and limits vary by plan, so check what you would need at your team size.
A custom app makes sense when your process is specific enough that off-the-shelf tools fight you, when you need the data to connect to your website or other systems, or when per-user subscription costs across a team start to add up.
What does a small custom app actually look like?
For this kind of job, “custom app” usually means something modest: a secure web app your team logs into, built on a standard database, with a handful of screens. Typically:
- A list view with search and filters, replacing the main sheet.
- A form for adding and editing records, with validation so bad data cannot get in.
- Roles, so staff, managers and contractors each see what they should.
- A change history on important fields.
- One or two connections: website enquiries arriving automatically, or records syncing to your accounting software or CRM.
- An export button, because someone will always want it back in a spreadsheet.
That is a focused build, not a programme of work. It runs in a browser on desktop and phone, and the data stays in accounts the business owns. Before anything is built, it is worth reading who owns your website: the same ownership questions apply to apps.
How do you scope the first version?
- Describe the job, not the spreadsheet. “We track each job from quote to invoice” is more useful than a list of columns.
- List the people who use it and what each one needs to do. This defines the roles.
- Mark the columns that matter. Most long-lived spreadsheets carry columns nobody uses. Leave them behind.
- Note where data comes from and goes to. Website forms, email, accounting software, a supplier portal. Each connection is a piece of integration work to scope separately.
- Write down the rules. “A job cannot be invoiced until it is marked complete.” Rules that live in people’s heads today become validation in the app.
- Pick the smallest useful version. Replace the most painful part first. Reports and dashboards can follow once the data is clean.
- Plan the cut-over. Decide when the spreadsheet becomes read-only, and how existing rows get imported and checked.
Our guide on how to brief a developer turns these notes into a one-page brief. A clear brief is the difference between a quote you can rely on and an open-ended project.
What about building it yourself with AI tools?
AI app builders can produce a working internal tool from a description, and for a single-user tracker that can be enough. Once real customer data and several staff are involved, the usual gaps apply: access rules, backups, and someone who can maintain it. Our articles on whether an AI-built app is safe to launch and fixing or rebuilding a vibe-coded MVP cover what to check.
If the spreadsheet holds personal information about customers, moving it into an app is a good moment to decide what you actually need to keep. Holding less data is simpler and safer.
If you only do three things
Count the hours your team spends retyping, reconciling and fixing the spreadsheet each week, list who needs to see what, and write down the rules people currently follow from memory. If those three lists are long, a small app is likely to pay for itself. If they are short, tidy the spreadsheet and revisit it in a year.
If it is time to move on, our custom web apps service builds small, focused apps like this at a fixed price, connected to the tools you already use. From $1,500. Most small apps and single features land between $1,500 and $4,000.
