Every business has at least one spreadsheet that started as a quick fix and quietly became mission-critical. It tracks orders, manages inventory, calculates commissions, schedules staff — and nobody is quite sure what will happen if it breaks.
Replacing it with custom software is not always the right move. Sometimes a spreadsheet genuinely is the best tool for the job. This checklist helps you figure out whether you have genuinely outgrown yours, what to prepare before talking to a developer, and what a realistic replacement looks like.
Part 1: Signs You Have Outgrown Your Spreadsheet
Score yourself honestly. If five or more of these apply, your spreadsheet is probably holding you back.
- Multiple people edit it simultaneously — You have had merge conflicts, overwritten data, or "who changed this?" conversations. Google Sheets helps, but at a certain scale even shared sheets become chaotic.
- You maintain multiple copies — There is a "master" version and backups or per-location variants. Nobody is 100% certain which one is current.
- It relies on manual copy-paste between sheets — Data from one tab gets manually transferred to another, or from an email into the sheet, or from the sheet into an invoice. Every manual transfer is an error waiting to happen.
- There is no audit trail — When a number changes, you have no way to know who changed it, when, or what the previous value was.
- Different people need different access levels — Your sales team should see their own figures but not everyone else's. Your manager needs the full picture. Your accountant needs export access. Spreadsheets do not handle permissions well.
- It takes ages to load — Thousands of rows, dozens of tabs, complex formulas that recalculate on every change. If people avoid opening it, the data stops being maintained.
- You have built workarounds on top of workarounds — Conditional formatting that acts as validation. VLOOKUP chains that reference other VLOOKUP chains. Hidden columns that drive other calculations. If only one person understands how it works, you have a single point of failure.
- You spend hours on reports — Generating a weekly or monthly summary means manually rearranging data, building pivot tables, and copying numbers into a presentation. The report should generate itself.
- Data entry errors cause real problems — Typos in a customer name, a decimal in the wrong place, a date entered as text. Without input validation, errors compound downstream.
- It does not connect to anything else — Your spreadsheet is an island. Data that exists in your POS, your website, your email system, or your accounting software has to be manually re-entered.
Part 2: What to Document Before Talking to a Developer
If you have decided it is time, the single most useful thing you can do is document your current spreadsheet thoroughly. A developer can turn a well-documented spreadsheet into a spec much faster (and cheaper) than starting from a vague conversation.
Who uses it?
- List every person or role that touches the spreadsheet
- Note what each person does with it: data entry only, data entry and reporting, read-only, admin
- Note how often each person uses it: daily, weekly, monthly
- Note what device they use: desktop, phone, tablet. This affects whether you need a mobile-friendly interface.
What data does it hold?
- List every column heading and what it means (do not assume the developer will understand "Ref2" or "JM Status")
- Note which fields are free text and which come from a fixed set of options (dropdown lists, yes/no, status codes)
- Note any relationships between sheets or tabs: "the customer name in Sheet2 must match a name in Sheet1"
- Note how much data it contains: hundreds of rows? Thousands? Tens of thousands?
- Note how fast it grows: ten rows a day? A hundred a week?
What breaks?
- List the most common errors, frustrations, and time sinks
- Note any data you have lost or had to reconstruct
- Note any processes that have been abandoned because the spreadsheet made them too difficult
What is manual that should not be?
- List every step where someone copies data between systems
- List every report that is assembled by hand
- List every notification or reminder that is sent manually (follow-ups, reminders, alerts)
What does the output look like?
- Save copies of any reports, exports, or summaries generated from the spreadsheet
- Screenshot any dashboards or summary views you have built within the spreadsheet
- Note where the output goes: email, print, another system, a client portal
Part 3: What a Realistic MVP Replacement Looks Like
You do not need to replace every feature of your spreadsheet on day one. A well-scoped MVP (minimum viable product) replaces the core workflow and adds the safeguards your spreadsheet lacks. You can add features later once the foundation is solid.
What a typical MVP includes
- Web application with login — accessible from any device with a browser. No software to install.
- User roles and permissions — different people see and do different things based on their role
- Data validation — the system enforces rules (required fields, correct formats, valid ranges) so bad data cannot get in
- Audit trail — every change is logged with who, when, and what the previous value was
- Search, filter, and sort — faster and more reliable than spreadsheet filtering, especially at scale
- Basic reporting — the summary views and reports you currently build by hand, generated automatically
- Data export — CSV or Excel export so you can still use spreadsheets for ad-hoc analysis
- Data import — a one-time migration of your existing spreadsheet data into the new system
What is usually added after the MVP
- Integrations with other systems (POS, accounting, email, Shopify, etc.)
- Automated notifications and reminders
- Advanced reporting and dashboards
- API access for connecting to other tools
- Mobile-specific features (offline access, camera/barcode scanning)
Part 4: Rough Cost and Timeline Expectations
These are ballpark figures for a custom web application built by a small studio like ours. They are not quotes — every project is different — but they give you a realistic starting point for budgeting.
Simple replacement (one user type, one core workflow)
- Examples: a job tracker, a client log, a simple inventory system
- Timeline: 4–8 weeks
- Budget range: £3,000–£8,000 / $4,000–$10,000
Medium replacement (multiple user types, several workflows, basic integrations)
- Examples: a commission tracking system, a booking and scheduling tool, a multi-location inventory manager
- Timeline: 8–16 weeks
- Budget range: £8,000–£20,000 / $10,000–$25,000
Complex replacement (enterprise-like features, multiple integrations, high data volumes)
- Examples: a full CRM, a multi-department workflow engine, a system processing thousands of records daily
- Timeline: 16–30+ weeks
- Budget range: £20,000–£50,000+ / $25,000–$60,000+
Ongoing costs
Once built, a custom web app typically costs £50–£200/month to host and maintain (hosting, database, SSL, monitoring). Feature updates, bug fixes, and support are usually billed separately, either hourly or as a monthly retainer.
Part 5: Red Flags to Watch For
Whether you work with us or someone else, watch out for these when evaluating developers:
- No fixed-price option — "we'll bill by the hour and see how it goes" is a recipe for budget overruns. A good developer should be able to give you a fixed price for a defined scope.
- No discovery phase — if someone quotes you without thoroughly understanding your spreadsheet and workflow, the estimate is a guess.
- No ownership of code — you should own the code that is built for you. If the developer retains ownership, you are locked in.
- No plan for data migration — your existing data needs to move from the spreadsheet to the new system. If this is not discussed upfront, it will be a painful afterthought.
- Overengineering — if the proposal includes AI, blockchain, microservices, or a mobile app for a problem that is currently solved by a 50-row spreadsheet, step back and ask why.
The Decision Framework
Ask yourself these three questions:
- Is this spreadsheet costing me time every week? Time spent fixing errors, manually transferring data, building reports, or answering "which version is correct?" Count the hours honestly.
- Is this spreadsheet creating risk? Data loss, security concerns (sensitive data in an unprotected spreadsheet), compliance issues, or single-person dependency.
- Will this spreadsheet get worse as the business grows? More customers, more staff, more locations, more products. If the spreadsheet struggles now, it will break later.
If the answer to two or more is yes, it is probably time.
Send Us Your Spreadsheet
If you have a spreadsheet that is ready to be replaced, we would like to look at it. Send it over and we will scope an MVP for free — no obligation, no sales pitch. We will tell you what a replacement would look like, how long it would take, and what it would cost. If it turns out a spreadsheet really is the best tool for your situation, we will tell you that too.
Send us your spreadsheet →
Or take a look at our services and apps to see the kind of software we build.