Replacing a spreadsheet with an internal tool your team will actually use

There is a spreadsheet at the centre of your business. Approvals live in a colour code, handoffs happen when someone remembers to check a tab, and month-end depends on one person knowing which formulas not to touch. It works, until someone is on holiday.

You have probably tried to move away from it before. A few weeks after launch, the team was back in the sheet. As one developer put it, "the non-tech/business users would rather be in a spreadsheet than anywhere else" (HN). That is not stubbornness: the sheet is familiar and already holds the rules nobody wrote down.

This guide helps you decide whether it is time to replace the sheet, which step to replace first, how to test it with real work, and how to make the case to whoever signs.

Signs the spreadsheet has become the system

The problem starts when the sheet stops being a record and becomes the process itself. Look for these signs:

• One person is the system. Only they know which columns matter, and work stops when they are away.
• Copies multiply. There is a "final", a "final v2" and a version someone emailed to a supplier.
• Approvals happen outside the sheet. Someone signs off in chat or by email, then a row gets updated later, or not at all.
• Month-end means rework. The team spends days reconciling numbers that should already match.
• You cannot answer "who changed this?" There is no reliable audit trail, and permissions are either everyone or no one.

If three or more sound familiar, the spreadsheet is carrying more risk than it was built for. That does not mean it all has to go at once.

Map the real workflow, then pick one step

Map what people actually do

Before you choose a tool, write down how the work actually moves. The official process lives in a slide. The real one lives in habits and workarounds.

Sit with the people who use the sheet and walk through one recent example from start to finish. For each step, capture:

1. What triggers it: a new order, an invoice, a request in chat.
2. Who does it and who they hand it to next.
3. What they check before they move it on.
4. The unwritten rules: "we never approve over [amount] on a Friday", "red text means wait for finance".
5. The workarounds: the extra tab, the side list, the reminder in someone's calendar.

The workarounds matter most. Each one points to something the current setup cannot do, and each one must survive in the new tool or the team will rebuild it in a spreadsheet.

Replace one step, not the department

The temptation is to fix everything in one project. One developer warned that "there's no chance you capture all functionality needed by your business on the first pass" (HN). Choose the step on your map that scores highest on three questions:

• Where does the most rework happen? Errors caught late, numbers keyed twice, approvals chased by hand.
• Where is the risk highest? Money, customer data, or anything an auditor might ask about.
• Can it stand alone? The step should have a clear start and finish, so it can work while the rest stays in the sheet for now.

For example, imagine a purchase approval step. Requests arrive by email, someone copies them into the sheet, a manager approves in chat, and finance updates the row before month-end. Replacing only that step gives you one form, one approval, one record, and a clean export to the spreadsheet everything else still uses.

Prototype it and run a day of real work through it

A specification will not tell you whether the team will use the tool. A clickable prototype will. Build the smallest version of the chosen step, then ask the people who do the work to run a real day through it alongside the spreadsheet.

You can sketch one in Runwise Studio to put the screens and steps in front of people. It is a planning prototype for testing the workflow, not production software, so use realistic examples instead of real customer data.

During the test day, note where people hesitate, where they reach for the old sheet, and which unwritten rule the prototype missed. Each one is a change to make before anything is built for real.

Hi [team],

We are looking at replacing the [step name] part of our spreadsheet with a simple tool. Before we build anything, I would like your help testing a rough prototype.

What I am asking:
- On [day], run your normal [step name] work through the prototype as well as the spreadsheet.
- Use realistic examples, not real customer details.
- Note anywhere you get stuck, anything that is missing, and any rule you follow that the prototype does not know about.

It will take about [time] on top of your usual work. Nothing changes in how we work yet. Your notes decide whether we go ahead and what we change first.

Thank you,
[your name]

Decide ownership, permissions and maintenance before launch

A common fear about a custom tool is what happens later. Internal tools "always fall into (non-)maintenance hell once the dev ... leaves" (HN). You can plan around that before you build.

Agree these four points in writing:

• Business owner: the person who decides what the tool should do and approves changes. Usually you.
• Technical owner: who fixes it when it breaks, and how quickly. Name a person or a support agreement, not "the developer".
• Permissions: who can view, who can edit, who can approve. Write the roles down now, while they are simple.
• Handover: the code, hosting accounts and documentation sit in accounts your company owns.

Also agree a short monthly review where users bring change requests and the business owner chooses what goes in.

Make the business case and choose how to build

Count hours and errors

Whoever signs will ask what this saves. Answer in the units your team already counts: hours spent, errors corrected and delays at month-end. Do not estimate savings you cannot check. Measure the current step for two weeks and use those numbers.

Subject: Proposal to replace the [step name] spreadsheet step

Today, [step name] runs through our [spreadsheet name]. Over the last [period], the team spent about [hours] hours a week on it, corrected [number] errors, and month-end was delayed [number] times because of it.

The main risks are [risk 1, for example no approval record] and [risk 2, for example one person holding the process].

I propose we replace only this step with a simple tool, tested first as a prototype by [names]. The rest of the process stays in the spreadsheet for now.

Expected cost: [build cost] plus [monthly running and support cost].
Owner: [business owner]. Technical support: [person or provider].
Decision needed by: [date].

No-code or custom

Neither option is right by default. Choose based on the step you picked.

No-code tools such as Airtable or similar platforms suit you when the step is simple, your team is comfortable configuring it, and the platform's permissions fit your roles. They are quick to start. The trade-offs can show up later: costs that rise with the team, and limits on complex rules. One operations manager reported that "getting through the permissions configurations ... took me many days" (Capterra).

A custom tool suits you when the rules are specific to your business, when you need a proper audit trail, or when it must connect to systems the platforms do not support well. It costs more up front and needs a named maintainer.

Ask one test question: if your no-code builder left tomorrow, could someone else understand and change the setup? If the answer is no, you already have a custom tool, just without the documentation.

Common mistakes

• Replacing the whole department at once. Fix one step, prove it, then move to the next.
• Mapping the official process. Map what people actually do, including workarounds, or the team will rebuild them in a new sheet.
• Testing with a demo instead of a working day. Run a real day of work through the prototype, using realistic examples in place of customer data.
• Launching without an owner. Name the business owner and technical owner before anything goes live.
• Promising savings you have not measured. Count hours and errors on the current step first.

Questions operations leads ask

Your next step

This week, pick one recent piece of work and walk it through the spreadsheet with the person who handles it. Write down each step, the unwritten rules and the workarounds, then mark the one step causing the most rework. That map is the brief for your prototype and the first paragraph of your business case.