Compare the 3 options honestly.
Spreadsheets run a lot of good businesses. The question is whether yours is still the right tool for how the work happens now.
| Option | Choose it when | Watch for |
|---|---|---|
| Keep and improve the spreadsheet | 1 or 2 people use it, the calculations are stable, and the main problems are layout, broken formulas, or missing validation. | Locked cells and data validation help, but duplicate versions and accidental overwrites tend to return as more people edit. |
| Use existing software | A product in your industry already handles most of the workflow, and your team can adapt to its way of working. | Per-user subscription costs, features you pay for and don't use, and steps the product can't match. |
| Build a web app | The rules are specific to your business, several people need the same data, or each job needs its own saved record that gets reopened and edited. | It needs a defined first release, an owner on your side, and hosting and care after launch. |
Many teams land in between. An improved spreadsheet can carry the work while a build is scoped, and a custom tool can connect to the software you keep.
Audit the workflow and the math first.
Whatever you choose, write down how the spreadsheet is actually used. This audit is useful even if you never build anything.
List every input.
Note which cells people type into, which come from another file, and which are copied in from somewhere else.
Trace each calculation.
Write each formula in plain language, including rates, markups, rounding, and minimums. Flag any formula only 1 person understands.
Mark the exceptions.
Record the jobs that need a manual override and why. Exceptions usually decide how complex a build becomes.
Note who touches it.
List who enters data, who reviews it, and who only needs the result.
Collect test cases.
Start with 3 to 5 completed jobs with known answers, then add edge cases, overrides, rounding, and error cases. These examples help define acceptance tests. The checks needed depend on the consequences of a wrong result.
Saved records for each job change how the tool works.
In a spreadsheet, a new job often means duplicating a tab or a file. In a web app, each job can be its own record with its inputs, results, status, and notes. Your team opens it, edits it, and saves it without touching the formulas.
| Spreadsheet habit | Web app equivalent |
|---|---|
| A tab or file per job | A list of saved jobs you can search, filter, and reopen |
| Typing inputs next to the formulas | A form for inputs, with the calculations kept separate and protected |
| A rates sheet anyone can edit | A settings area that approved people can change |
| Emailing the latest version | 1 shared record that everyone with access sees |
Decide this early: when your rates change, should saved jobs keep the rates they were created with, or recalculate? Both are reasonable. The answer shapes how records are stored and what your team sees when it reopens an older job.
Permissions and history are features you scope.
Spreadsheet sharing and protected cells can control access, but they may become hard to manage as roles and records grow. A web app can give each person access to the records and actions their role needs, with change history where the workflow requires it.
Identify the access controls the first release needs before anyone relies on it. A small internal team may need individual sign-ins and 1 administrator. Client-facing records may need separate roles and record-level access from the start. Agree how accounts are removed, who can export data, and when change history is required. Essential controls belong in the first release.
Plan the move and test before you rely on it.
Existing rows can often be imported, but older data usually needs cleanup first. Some teams start fresh and keep the spreadsheet as a read-only archive. Decide which before the build begins.
Before the tool replaces the spreadsheet, run agreed test cases through both and compare the results, including exceptions and failures. Your team confirms the business rules and expected answers. TMN tests the agreed implementation against them. The proposal names the acceptance criteria and who approves the changeover. A period of parallel use can help reveal gaps, but does not replace those checks.
Also agree what must be recoverable if a record is changed or deleted, how backups are checked, and how your team can export its data. A critical calculation, access rule, recovery path, or required integration belongs in the first release when the workflow depends on it.
What to send for a first conversation.
You don't need a specification. These are enough for a useful first call.
- A short description of the work the spreadsheet supports
- Who uses it and what each person does with it
- The tools it needs to work alongside
- A blank copy of the spreadsheet, or a sample with real details removed
- What a better version would let your team stop doing
Please keep confidential data out of the public inquiry form. Leave out client records, passwords, and financial account details. A blank template or a scrubbed sample is enough to start. If we need more, we'll agree a suitable way to review it.
How scope and pricing are set.
A custom web app is priced around its agreed first release: the workflow, users, data, calculations, and connections. Hosting and care are priced separately. You'll see both in a written proposal before work begins.
For defined dashboard and operations platform builds, TMN publishes starting scopes on the pricing page. They are not a price for every web app. The custom software overview explains how we evaluate fit, set a first release, and divide responsibilities.
Questions before you decide.
Will it work on phones?
A browser-based build can be designed for computers, tablets, and phones. We confirm the devices and browsers your team needs. Native app-store distribution is a separate requirement to discuss when scoping the project.
Can we keep using Excel or Google Sheets alongside it?
Sometimes. An import, an export, or a connection can be scoped when it serves the workflow. We confirm what your spreadsheet tool supports before quoting.
Who checks that the calculations are right?
We test against the acceptance criteria and examples agreed in the proposal. Your team confirms results against real work before relying on the tool.
What if our process changes after launch?
Changes are scoped and quoted before work begins, or handled under the care terms in your agreement.