Replace the Spreadsheet Everyone Is Afraid to Touch
Internal tools for the processes your business actually runs on — with real permissions, a history of who changed what, and integrations into the systems you already use. Built around how your team works, not how a process document says they should.
How These Projects Usually Start
What Changes When the Process Gets a Home
Not a claim about your business — a sketch of the difference in kind between a shared file and a tool built for the job.
The shared file everyone depends on
- Anyone with the link can edit any cell, including by accident
- No record of who changed a value, or why, or when
- The rules live in formulas and in one person's memory
- Other systems get updated by hand, or not at all
- Copies in circulation
- Several
- Change history
- None
One place, with rules and a memory
- People see and edit only what their role allows
- Every change is attributed, timestamped and reversible
- The rules are written down, tested, and the same for everyone
- Your other systems are updated automatically, both ways
- Copies in circulation
- One
- Change history
- Every edit
Illustrative comparison of the two ways of running a shared process — not measurements from a specific client engagement.
How to Spot a Process Worth Automating
The strongest candidates have most of these. If yours has one or two, spend the money elsewhere and we will say so.
It repeats, a lot
Volume is what pays for a build. Several people doing the same thing many times a week beats one person doing something elaborate once a quarter, every time.
Mistakes are expensive
If a typo becomes a wrong invoice, a missed delivery or a compliance problem, validation and an audit trail are worth real money on their own.
Data is re-entered by hand
Any point where a human retypes something one system already knows is both a cost and a reliable source of errors. These are the easiest wins to justify.
Someone needs to prove it happened
Auditors, insurers, clients or regulators asking who approved what and when. A file with no history cannot answer that; a tool answers it in seconds.
The delay is the problem
Work sitting in an inbox waiting for a person to notice it. Routing, reminders and a queue that shows what is stuck often matter more than any screen.
Growth will break it
A process that works at the current volume and visibly will not at twice it. Better to rebuild while it is calm than during the quarter when it collapses.
We Map What People Do, Not What the Document Says
Every company has a documented process and a real one, and the gap between them is where internal software projects die. The document says three approvals. In practice two of them are a nod in the corridor, and there is a fourth step nobody ever wrote down because the same person has always just done it.
So discovery is watching, not interviewing a manager. We sit with the people doing the work, ask them to run through it with a real case, and pay close attention to the workarounds — the sticky note, the second spreadsheet, the folder of emails. Workarounds are not bad habits. They are unwritten requirements, and a tool that ignores them gets abandoned within a month.
- Sessions with the people who actually do the work, not only their manager
- A written process map you correct, with every exception listed
- Steps marked as keep, fix or delete before anything gets built
- A clickable prototype signed off before production code starts
The Parts That Make It a System
Roles and permissions
- Who can see a record, who can edit it, and who can approve it are three different questions
- Field-level control matters — a coordinator may need the order without the margin on it
- Delegation and cover, so approvals do not stop dead while someone is on leave
- Designed early, because retrofitting permissions into a finished tool is genuinely painful
Integrations with what you run
- Accounting, CRM, payroll, inventory, email — whatever already holds a piece of the truth
- We agree which system owns each field, so nothing has two conflicting masters
- Where a system has no usable API we schedule imports or file drops rather than pretend — see backend and API work
- Every sync is logged and retried, with a screen showing what failed instead of silence
Data migration from spreadsheets
- We profile the real files first: duplicates, formats, blanks, and the columns nobody can explain
- Cleanup rules are agreed with you in writing, not guessed at by a developer at midnight
- The migration is rehearsed into a test system repeatedly until the result is boring
- Your original files stay untouched, and stay readable as a reference for a good while after
Reporting and audit trail
- Every change attributed and timestamped, because eventually someone will ask
- The handful of numbers management checks weekly, on screen instead of in an inbox
- Exports that still let people take a slice into a spreadsheet when they want to think
- Deeper analysis belongs on a proper dashboard rather than bolted into the tool
These Projects Fail at Adoption, Not at Code
We have rarely seen an internal tool fail because the software did not work. We have often seen one fail because people went back to the spreadsheet in week three.
Pick who goes first, and tell them why
A small group who feel the pain most, brought in during discovery so the tool arrives as something they helped shape rather than something imposed on them. Their endorsement is worth more than any amount of internal email.
Run the old way alongside for a short, fixed period
A parallel run builds confidence and catches the cases nobody mentioned. It has to have an end date, though. Parallel running with no deadline is how a business ends up maintaining two systems forever.
Train on real work, in small groups
Not a demo of every feature. People sit down with their own live cases and complete them in the new tool, with someone beside them. Thirty focused minutes beats a two-hour presentation nobody retains.
Fix the first-week complaints immediately
The early friction is small and fixable: a field in the wrong order, a missing filter, one extra click on the busiest screen. Fixing those within days is what convinces people this tool is theirs. Leaving them for the next release is what sends them back to the file.
Retire the spreadsheet properly
On an agreed date, made read-only, with the reason announced by someone senior. As long as the old file is still editable, some of your data will keep going into it — and half-migrated is worse than either option.
Build, Buy, or Leave It Alone
We would rather talk you out of a build than sell you one you regret. This is roughly how the conversation goes.
The process is part of your edge
If the way you quote, schedule or fulfil is a reason customers choose you, a generic product will flatten it into everyone else's way of working. That is the clearest case for custom software there is.
Off-the-shelf only fits after heavy surgery
When the product needs six custom fields, four automations and a consultant on retainer to keep it upright, you are already paying for a custom build — just one you do not own and cannot fix yourself.
It is a solved, ordinary problem
Accounting, payroll, email marketing, helpdesk ticketing. Mature products exist, they are cheap, and thousands of people have already found the bugs. Building your own version of one is a hobby, not a strategy.
You need it working next month
Buy now, and build later if the fit turns out to be genuinely wrong. A tool live on Monday that fits eighty percent beats a perfect one arriving after the deadline that mattered.
The process is still changing every week
Software makes a process concrete, which is a problem when it is still being invented. Let it settle first, keep the spreadsheet a little longer, then build the version that stays.
Nobody internally will own it
Every successful rollout has one person inside the business who wants it to work and has the standing to make decisions. Without that person, the best tool we can build will be quietly abandoned.
Questions About Internal Tools
How do we know a process is worth automating?
Count three things: how many people do it, how often they do it, and what a mistake costs. A task six people repeat daily where an error means a wrong invoice is worth building for. A task one person does monthly in twenty minutes almost never is, however annoying it feels. We work that out with you before quoting, and we say so when the answer is no.
Will this replace our spreadsheet completely?
The shared process, yes. The spreadsheet as a thinking tool, deliberately not. Spreadsheets are excellent for one-off analysis and poor as the system of record for work several people touch. We move the shared process into a tool with real permissions and history, and keep a clean export so anyone can pull a slice into a spreadsheet whenever they want to model something. Removing that option is how a shadow copy ends up on a private laptop.
How long does an internal tool take to build?
A focused first version covering one process is typically six to twelve weeks, including discovery and migrating the data you already have. Larger systems with several roles, approval chains and integrations run longer. We sequence it so one team gets something genuinely usable early rather than everybody waiting for everything, and you see a working build every two weeks.
What happens to the data we already have?
We migrate it, and that work is always bigger than it looks. Real spreadsheets contain merged cells, three date formats, the same customer spelled four ways, and rows that make sense only to the person who added them. We profile the data first, agree the cleanup rules with you in writing, run the migration repeatedly into a test system until it is boring, and leave your original files untouched as a reference.
Should we buy something off the shelf instead?
Sometimes, and we will tell you plainly. If your process is close to the way a common product already works, buying is cheaper and you get improvements without paying for them. Custom earns its place when the process is part of what makes you competitive, when the off-the-shelf option only fits after configuration so heavy nobody can maintain it, or when per-seat pricing across a large team costs more every year than building once would.
Show Us the Spreadsheet
Describe the process and who touches it. We'll come back with whether it is worth building, what it would take, and whether you would be better off buying something.