On this page
Key takeaways
- The cost of an internal tool is not the build; it is the build plus the operating life.
- Price the workaround first: hours, errors, and delays that the spreadsheet already causes.
- Count the risks that do not show up in payroll: a missed exception, a wrong invoice, a person leaving.
- Sometimes the right answer is to improve the spreadsheet and wait.
Every operations team has a workaround that quietly consumes hours: a shared workbook, a chain of emails, a report someone rebuilds every Monday. The question is not whether it is annoying. It is whether it is expensive enough, risky enough, and stable enough to justify replacing.
This worksheet is the method we use with teams before discussing any build. It works whether you hire a studio, buy a product, or build in-house.
Step 1: Describe the workaround precisely
Vague problems produce vague estimates. Write it as a sequence: what triggers it, who touches it, what tools it crosses, and what the output is.
Step 2: Price the workaround
| Cost | How to estimate it | Example |
|---|---|---|
| Direct hours | People × minutes per occurrence × occurrences per month | 3 people × 20 min × 60 = 60 hours |
| Rework | Errors caught later × time to fix | 8 corrections × 30 min = 4 hours |
| Delay | What waiting costs: late invoices, missed windows | Morning close takes 41 minutes |
| Risk | Chance of a missed item × its consequence | One missed hold in a quarter |
| Key-person | Cost if the one person who knows it leaves | Two weeks to reconstruct |
The hidden line
Risk and key-person cost rarely appear on a timesheet, and they are often the real justification. Write them down even if the numbers are rough.
Step 3: Price the alternatives
| Option | Cost shape | Good when |
|---|---|---|
| Improve the spreadsheet | Small, one-off | Volume is low or the process is still changing |
| Buy existing software | Licence plus configuration | A product already matches how you work |
| Commission a build | Build plus operating life | The workflow is specific and stable enough to write down |
| Do nothing | The workaround cost, continuing | The number from step 2 is genuinely small |
Include the operating life. Every system needs an owner, upgrades, and a review after launch. Budget for the ninety days after go-live, not just the build.
Step 4: Check readiness
You are ready to build when
- The process has been stable for at least a few months.
- You can name the person who will operate the result.
- You can list what the system will not do.
- The existing system of record will stay in place.
- There is a way to measure success that is not 'people like it'.
Wait, and refine the sheet
- The process changes every month
- Nobody owns the outcome
- The cost is small and the risk is low
Build or buy now
- The workaround costs hours and risk every week
- A person will own and operate it
- The scope can be written on two pages
Step 5: Decide, and define the first cut
If the numbers justify it, do not scope the whole system. Pick the single most painful step and design the smallest complete cut around it. At Halcyon that was an exception queue, assignment, and a morning digest; the morning close fell from 41 minutes to 12 in the first release.
A worked example, step by step
The figures below are invented to demonstrate the arithmetic. Substitute your own.
| Item | Assumption | Result |
|---|---|---|
| Occurrences per month | 60 exceptions | — |
| Time per occurrence | 3 people × 20 minutes | 60 hours per month |
| Rework | 8 corrections × 30 minutes | 4 hours per month |
| Morning close | 41 minutes × 22 working days | 15 hours per month |
| Total recurring effort | 60 + 4 + 15 | 79 hours per month |
| Loaded hourly cost | Assumed 40 (currency units) | 3,160 per month, about 37,900 per year |
Against that recurring cost, compare the first-year cost of the alternatives: the build plus its operating life, or the licence plus configuration. Divide the difference by the monthly saving to get a payback period.
annual_workaround_cost = 37,900
expected_reduction = 60% # be conservative; measure after launch
annual_saving = 37,900 * 0.60 = 22,740
first_year_cost (build + operate) = 30,000 # placeholder
payback_months = first_year_cost / (annual_saving / 12)
= 30,000 / 1,895 = ~15.8 monthsAdd what the timesheet misses
Risk and key-person cost usually change the answer. A single missed hold, a wrong invoice, or a resignation can cost more than a year of hours. Put a rough number on them and show it as a separate line so readers can discount it if they wish.
Test the answer's sensitivity
| If this is wrong | Effect on payback | What to do |
|---|---|---|
| Reduction is half what you assumed | Payback doubles | Find a cheaper first cut or validate with a pilot |
| Occurrence volume is lower | Payback lengthens | Reconsider: improve the sheet instead |
| Operating cost is higher | Payback lengthens | Include a realistic owner and review time |
| Risk cost is real | Payback shortens sharply | Document the risk and involve its owner in the decision |
Nielsen Norman Group's writing on the return on investment for usability [1] makes a related point: the value of improving a tool is often measured in the small, repeated costs that people have stopped noticing.
Build, buy, or configure?
| Option | Cost shape | Risks | Choose when |
|---|---|---|---|
| Improve the spreadsheet | Very low | Continues the key-person and audit risk | The process is still changing |
| Low-code or configuration of an existing product | Low to medium | Fitting your workflow to the tool's model | A product already matches how you work |
| Buy a product that matches | Licence and configuration | Vendor roadmap, integration effort | The workflow is common in your industry |
| Commission a custom build | Highest upfront; lowest long-term mismatch | Needs an owner and operating life | The workflow is specific and stable |
Adoption risk factors to score before you commit
Score each 0–2; below eight is a warning
- A named owner will operate and improve it.
- The process has been stable for a quarter or more.
- The people who do the work were involved in defining it.
- The existing system of record will remain in place.
- A dated plan retires the old workaround.
- Success can be measured without asking whether people like it.
Governance so it stays useful
- An owner with a budget of time. A tool nobody owns decays; give someone a few hours a month.
- A change process. Requests go into a visible queue with the metric each should move.
- Quarterly review. Check adoption, workarounds, and cost against the original case.
- A retirement condition. Decide what would make you switch it off or replace it.
A one-page summary you can send upward
Workaround: ______________________
Occurrences/mo: ____ Hours/mo: ____ Rework hrs: ____
Risk: ______________________
Key-person: ______________________
Best alternative: [ ] improve [ ] buy [ ] build [ ] wait
Operator: ______________________
Non-goals: ______________________
First cut: ______________________
Review at 30 and 90 days: [ ]If the answer is a build and you want a partner, we take selected teams with a written problem and a named operator. Northframe is the product to look at first if the workaround is an after-hours exception process.
References & further reading
- 1Return on Investment (ROI) for Usability — Kara Pernice, Jakob Nielsen, Nielsen Norman Group
- 2Shape Up: Stop Running in Circles and Ship Work that Matters — Ryan Singer, Basecamp
- 3Continuous Discovery Habits — Teresa Torres, Product Talk
The product behind this post
Northframe
The operations layer for teams who still run the night shift.
From $890 per month
About the authors
Emily Sinclair
Head of Product
Leads Northframe and Meridian, and the discovery work that turns shadow spreadsheets into products.
Omar Farouk
Engagement Lead, Services
Scopes and leads selected client builds, and helps startups and agencies decide what to build first.
Product behaviour described here reflects what is implemented and tested; anything else is marked as planned. Code samples are illustrative.
All writing