Internal Tools: The Software Investment Hiding in Your Spreadsheets
Spreadsheet sprawl is unbudgeted software. See the census, prioritization scorecard, low-code vs custom choice and ROI math that turn workbooks into internal tools.
Somewhere in your business is a spreadsheet that runs a real process. Not a list — a process: orders move through it, invoices depend on it, and if it broke tonight, tomorrow would hurt. That workbook is software your company already built by accident — and it deserves the same conversation as any other investment: what it costs, what it risks, when to replace it.
This article is that conversation. We follow Kestrel Foods, a modeled 45-person food distributor — three warehouses, roughly 600 orders a week, 38 active workbooks — where every Kestrel number is illustrative and published figures are attributed. We walk through the census, the signals that say "build now," the scorecard, the data-model-first discipline, low-code versus custom, the ROI math and a 90-day rollout plan.
Here is the short version.
Key Highlights
- The modeled distributor runs 38 active workbooks in weekly use — 11 owned by a single person who could leave any Friday.
- Field audits reviewed by Ray Panko (University of Hawaii) found roughly 88% of spreadsheets contain errors.
- The modeled team spends 21.5 staff-hours a week feeding its workbook cluster — about 1,000 hours a year.
- Roughly a dozen corrections a week come from mis-keyed prices, addresses and quantities (modeled).
- Gartner predicted 70% of new applications would be built with low-code or no-code tools by 2025, up from under 25% in 2020.
- A scoped internal tool costs a modeled $9,000-$18,000 and pays back in 10-25 months.
- The modeled three-year bill for doing nothing is $93K of hidden labor — versus $36K for a low-code platform and $52K for a custom build.
- Gartner expects a third of successful cyberattacks to target shadow IT resources by 2027, and ungoverned spreadsheets are shadow IT.
The Spreadsheet Baseline: Take a Census Before You Build
Most businesses cannot answer the first question: how many spreadsheets are running the company? The estimate lives in folklore because nobody has counted, so count. List every weekly workbook, its owner, what would break without it and the hours a week it consumes.
The Kestrel census turned up 38 workbooks in weekly use — five of them less spreadsheets than load-bearing infrastructure, together consuming 21.5 staff-hours a week. Here is the cluster that carried the business:
| Workbook cluster | What it runs | Owner situation | Modeled hours/week |
|---|---|---|---|
| Order-desk tracker | Order status from intake to delivery | Two people, no backup | 6.5 |
| Invoicing and statements | Who owes what, who was billed | Finance lead | 5.0 |
| Driver schedules | Routes and delivery windows | One dispatcher | 4.5 |
| Inventory counts | Weekly counts and reorder nudges | Warehouse leads | 3.5 |
| QC and compliance logs | Temperature and lot checks | Part-time QA owner | 2.0 |
Twenty-one and a half hours a week is half an employee doing a machine's job. Across 48 working weeks that is about 1,000 hours a year, at a modeled loaded cost of $30 per hour — roughly $31,000 a year paid to avoid building software. The census also surfaced the fragility: 11 workbooks had exactly one owner, and six had broken visibly at least once last quarter.
Key takeaway: A spreadsheet that runs a weekly process is not a file — it is unmanaged software. Count it, name its owner and price its hours before you spend anything on new tools.
Signal 1: The Errors Compound Quietly
Spreadsheet errors rarely announce themselves; they surface as credits, late deliveries and arguments about whose number is right. Ray Panko, a University of Hawaii professor who has reviewed decades of field audits, found roughly 88% of spreadsheets contain errors — most small, all cheaper to prevent than to catch. Untyped cells, silent copy-paste and hidden formulas give errors a thousand places to hide.
At the modeled Kestrel order desk, errors showed up as corrections — about a dozen a week, half of them pricing:
Each correction costs 10-20 minutes plus the occasional credit note, and one mis-priced wholesale line can erase a month of margin on that account. The second cost is quieter: ungoverned spreadsheets sit outside IT's security perimeter — Gartner expects a third of successful cyberattacks to target shadow IT resources by 2027, and a customer list in a personal workbook is exactly that: valuable data nobody patches, backs up or audits.
Key takeaway: Errors and exposure are the real spreadsheet bill — budget for correctness, audit trails and access control, not just convenience.
Step 1: Pick the First Tool With a Scorecard, Not a Guess
Every team has a favorite: the warehouse wants the inventory app, sales the CRM sweep, finance everything. Prioritization fails when it runs on enthusiasm, so score the candidates instead. Two numbers decide most of it — hours saved per week and build cost — with error pain as the tiebreaker.
We value a saved hour at $45 for Kestrel: $30 of loaded wage plus overhead, plus the cost of the errors those hours currently cause. That assumption is visible on purpose. Here is the scored shortlist:
| Candidate tool | Hours saved/wk (modeled) | Annual value (modeled) | Build cost (modeled) | Payback |
|---|---|---|---|---|
| Quote builder for wholesale reps | 5.0 | $10,800 | $9,000 | 10 months |
| Order-desk status portal | 6.5 | $14,000 | $18,000 | 15 months |
| Invoicing automation | 5.0 | $10,800 | $11,000 | 12 months |
| Driver schedule board | 4.5 | $9,700 | $14,000 | 17 months |
| Inventory count app | 3.5 | $7,600 | $16,000 | 25 months |
The quote builder wins first place despite saving fewer hours, because it is cheap and the reps feel the win immediately. Sequence matters: cheap, visible wins fund patience for the bigger builds — and after a scorecard, nobody argues about what gets built first.
Key takeaway: Rank candidates by hours saved against build cost with a visible hourly assumption, and let the first tool be the clearest payback, not the loudest request.
Step 2: Design the Data Model Before Any Screens
The fastest way to waste a tool budget is rebuilding each spreadsheet's private dialect in a new interface. Workbooks encode quirks — statuses typed three ways, customers spelled two, quantities meaning cases here and units there. A new tool inherits all of it unless the data gets designed first.
So start with nouns and verbs — the entities the business runs on and the events connecting them. For the modeled Kestrel order flow, the core model is six entities:
| Entity | Core fields | Replaces |
|---|---|---|
| Customer | Name, terms, delivery address, price list | Contact tabs in three workbooks |
| Order | Customer, lines, status, promised date | The order-desk tracker |
| Invoice | Order, amount, due date, paid date | The invoicing workbook |
| Shipment | Order, driver, window, proof of delivery | The driver schedule board |
| StockCount | Site, SKU, counted qty, counter, date | The inventory count workbook |
| QCCheck | Site, lot, temperature, pass/fail, date | The QC log |
Three rules keep the model honest: one canonical record per real-world thing, statuses drawn from a fixed list rather than free text, every record stamped with who created it and when. None of that is glamorous; all of it is what spreadsheets cannot give you, and a sound data model compounds long after the screens change.
Key takeaway: Design the nouns and verbs of the business before choosing any platform — the data model is the part of an internal tool that outlives every screen.
Step 3: Choose the Build Approach — Configure, Low-Code, or Custom
With the model drawn, the build question has three answers. Configure an off-the-shelf database tool — Airtable- or Smartsheet-style — for list-and-form workflows. Low-code platforms such as Retool, Power Apps or Glide assemble real applications on your databases with drag-and-drop plus escapes into code. Custom development builds exactly the tool, on your stack, owned outright.
The low-code route has become the mainstream default: Gartner predicted that by 2025, 70% of new applications developed by organizations would use low-code or no-code technologies, up from less than 25% in 2020. But the label hides a spread:
| Factor | Configure off-the-shelf | Low-code platform | Custom build |
|---|---|---|---|
| Time to first usable version (modeled) | Days to 2 weeks | 2-6 weeks | 6-12 weeks |
| Modeled cost band | $1K-$8K | $8K-$30K | $30K-$80K |
| Ongoing cost | Per-seat fees | Platform subscription | Care and hosting |
| Data model | Must fit the tool's shape | Yours, within platform limits | Exactly yours |
| Best for | Experiments, simple lists | Ops tools on clean models | Core IP, deep integrations, compliance |
| Watch out for | Process contortion | Export limits and lock-in | Cost, time, maintenance burden |
We watched the low-code pattern work at enterprise scale in our low-code insurance operations case study: a regional insurer ran 14 spreadsheet tools alongside a core system where any change took a nine-month development cycle; a governed low-code build replaced the queue without replacing the mainframe. The lesson scales down: the approach is a staffing and risk decision, not a fashion decision.
Choose custom when the workflow is core intellectual property, compliance requires an environment you control, or the tool must reach systems the platforms cannot; otherwise, buy the boring option.
Key takeaway: Configure for experiments, build low-code for operations on clean data models, and reserve custom for what the business genuinely cannot run without.
Step 4: Do the ROI Math Out Loud
Internal tools fail politically more often than technically; the antidote is math everyone can audit. At Kestrel, the first three tools — quote builder, order-desk portal and invoicing automation — target 16.5 of the 21.5 spreadsheet hours. At $30 per loaded hour, that is roughly $23,800 a year returned, before counting the corrections that stop happening.
The modeled cost side: low-code with setup and subscriptions runs about $18,000 in year one and $9,000 a year after; custom runs about $40,000 up front plus annual care. Against the status quo of $31,000 a year in hidden labor, the low-code route pays back in roughly nine months, the custom build in about twenty. Here is the same model over three years:
The chart's quiet point: doing nothing is not the cheap option — by year three the "free" spreadsheets have cost $93,000 in labor, the low-code platform $36,000 and the custom build $52,000. The custom build carries the deeper integrations and ownership the platforms cannot.
One honest caveat: hours saved are only real if someone redeploys them. Kestrel's plan moves the order desk's recovered time to customer follow-up and claims handling — work that was queueing; savings without a destination evaporate into slower days.
Key takeaway: Write the ROI as one auditable paragraph — hours, loaded rate, cost, payback — and if it does not clear inside roughly two years, question the scope, not the spreadsheet.
Step 5: Roll Out, Retire and Measure the Savings
Rollout is a discipline, not an event: pilot with two or three users, run the tool in parallel with the workbook for two weeks, and cut over when the totals agree. Then comes the step everyone skips: retire the workbook — archive it read-only, strip it from shared drives, and explain why it can no longer be edited.
The ramp is realistic, not linear: months one and two capture the quote builder, months three and four the order desk, and invoicing lands around month five. By month six the modeled team has 16.5 of the 21.5 hours back each week — about 79% of the silo tax — and the corrections line has dropped by roughly the two-thirds that came from pricing and address errors. Measure weekly at first, then monthly.
Ownership decides whether the savings stick. Kestrel gave the tools to an operations lead who owns the roadmap, the access list and the annual review; the same pattern as our logistics admin-panel case study, where a team absorbed growing exception volume only once the tooling had a named owner. When the numbers hold, run the scorecard again for tool number four — our energy analytics platform shows where this road ends: report assembly retired into live dashboards.
For what to connect next, see our business automation ideas; our custom software comparison covers when an internal tool stops being internal and becomes a product.
Key takeaway: A tool is not finished when it ships — it is finished when the workbook is retired, the savings are measured weekly, and one named owner is accountable for both.
What Your Business Should Do
Here is the 90-day plan we give clients ready to stop paying the spreadsheet tax:
Days 1–30: Take the census.
- List every weekly workbook with its owner, purpose and feeding hours; flag single-owner files.
- Measure one honest week: feeding hours, plus every correction and apology they caused.
- Score the candidate tools on hours saved versus build cost with a visible hourly rate, and pick one pilot.
Days 31–60: Design, build and parallel-run.
- Model the pilot workflow's data — entities, fixed statuses, ownership stamps — before choosing any platform.
- Build the first version configured or low-code, unless the scorecard and compliance needs genuinely demand custom.
- Run it beside the workbook for two weeks and cut over only when the totals agree.
Days 61–90: Retire, measure and sequence.
- Archive the workbook read-only, remove it from shared drives, and publish the savings math: hours, rate, payback.
- Assign a named owner for the tool, its access list and its backlog.
- Run the scorecard again for the next tool; set an annual review for subscriptions, security and access.
The Bottom Line
The spreadsheets are not the problem; they are the receipt. Kestrel's modeled numbers are ordinary on purpose — 38 workbooks, 21.5 hours a week, a dozen corrections, roughly $93,000 over three years — and every one of them is measurable in your business within a fortnight. The companies that treat internal tools as an investment portfolio — scored, sequenced, owned — are quietly building the operations their competitors will try to buy later.
If you want a second pair of eyes on which spreadsheet to replace first, that is literally what we do all day. Book a free strategy call and we will run the census with you, score the candidates and scope the first build — or send us a message with your questions and we will answer within one business day.
Free download: the Learning Guide (PDF)
Everything worth keeping from this article — key numbers, tables and the action checklist — in one print-ready, fillable PDF.
Join our newsletter — more growth tips, twice a month
Playbooks from real projects. No spam, unsubscribe anytime.
FAQ
When is a spreadsheet actually a problem?+
Three signals: volume, fragility and concentration. If a workbook is touched daily by several people, breaks visibly and has one owner, it is no longer a spreadsheet — it is ungoverned software. Panko's field audits put error rates near 88%, and the cost shows up as corrections, credits and decisions made on numbers nobody trusts.
Should we start with low-code or a custom build?+
Start low-code when the workflow is standard, the data model is clean and the tool must ship in weeks. Go custom when the workflow is core intellectual property, compliance requires an environment you own, or the tool must integrate deeply with systems platforms cannot reach. Most businesses run both: low-code for operations, custom for the one or two systems that define the company.
How much does an internal tool cost to build?+
The modeled ranges run from about $9,000 for a configured tool to $18,000 first-year for a low-code build with subscriptions, and $40,000 and up for custom development plus care. Cost is driven less by screen count than by data cleanup and integrations. Budget the build once and the care annually, and measure payback against the hours the workbook already costs you.
Who should own internal tools inside the company?+
An operations leader, not IT and not the spreadsheet's current author. IT should govern security, access and backups; the business owner should own the roadmap and the metrics. The failure pattern is predictable: tools owned by nobody drift back toward the workbook.
Engineering-led team at Emerson Technology — building apps, web platforms and growth systems for ambitious businesses. Every guide comes from real client work.