Every operations platform we have built has replaced the same handful of disconnected tools, and the conversation that starts it sounds the same every time. One tool for hiring, another for scheduling, another for payroll, and a spreadsheet holding the whole thing together.
On one of those projects the five were hiring, delivery logistics, payroll, and tax reporting, with a spreadsheet acting as the connective tissue between them. Each tool did its job well enough. What none of them did was own the workflow end to end, which meant a person had to, and that person’s real job had quietly become moving data between systems that were never designed to talk to each other.
This post is about what replacing that arrangement actually involves, what it changed, and the requirement we missed while doing it. If you are still deciding whether custom is the right call at all, the build-versus-buy question comes first and this post assumes you have already answered it.
How five tools happen
Nobody sits down and chooses to run a business across five disconnected systems. It accumulates, one reasonable purchase at a time. Hiring got painful, so somebody bought a hiring tool. Then logistics got painful. Then payroll. Each purchase solved a real problem on the day it was made, and each one was the right call in isolation.
The scale of this is easy to underestimate. Okta’s SMBs at Work 2024 report, drawn from over 18,000 companies in its own customer base, found that businesses with 50 or fewer employees deploy around 36 apps, and that SMBs average 58. Those numbers only count applications under managed identity, so the real figure is higher once you add the spreadsheets and shared documents nobody registered anywhere.
No single tool is at fault here. The workflow crosses all five of them, no tool owns the crossing, and so the integration layer ends up being a person with a copy-paste habit and a good memory.
The spreadsheet is the tell
There is almost always a spreadsheet, and it is almost always the first thing to break.
It breaks quietly, which is what makes it dangerous. Someone forgets to update it after a change, or copies the wrong row, and now two systems hold different versions of the same fact with nothing to indicate which one is right. Nobody notices at the moment it happens. It surfaces later, when a number in a report does not match a number in a system, and somebody spends an afternoon working out which one to believe.
Copying costs minutes. Reconciling afterwards costs hours, and in the gap between the mistake and the discovery, decisions get made on the wrong number.
Five signals the tools have become the problem
Tool sprawl is normal and mostly harmless until it crosses a line. These are the five signals we look for, and any two of them together usually mean the workflow has outgrown the arrangement.
- A person is the integration layer. Someone’s actual daily work is moving data from one system into another. It is rarely in their job description and it is usually the first thing to slip when they are busy.
- Two systems disagree and nobody knows which is right. If a recurring meeting exists mainly to reconcile numbers between tools, the meeting is a symptom.
- The spreadsheet has become load-bearing. It holds data that no system owns, and exactly one person fully understands how it works.
- Onboarding means five accounts and a tour. Access lives in five places, which means offboarding misses one, and nobody can answer “who can see payroll” without opening five admin panels.
- A simple question takes three logins to answer. When reporting requires assembling data by hand, it happens monthly instead of daily, and the business runs on numbers that are three weeks old.
What we built
One platform, four workflows, one data model. That last part is the whole point, and everything else follows from it.
Role-based access. Hiring sees hiring, payroll sees payroll, and a manager sees across both. This replaced five separate account systems with one place to grant and revoke, which is the difference between offboarding being a checklist item and offboarding being a thing you hope somebody remembered.
Dashboards on live data. The question that used to take three logins and a manual assembly step became a page. This is the change people notice first, because it converts reporting from a monthly exercise into something you can just look at.
Document generation. The paperwork and reports that were previously assembled by hand now come out of the system that already holds the data. Anything generated from the source of truth cannot disagree with it, which removes a whole category of error rather than reducing it.
Integrations with the systems that stayed. Consolidation does not mean replacing everything. Some external services had to remain, so the platform talks to them directly instead of a person retyping between them. The test for whether a tool gets replaced or integrated is simple: if the workflow needs to own the data, replace it; if the workflow only needs to read or send it, integrate.
An automation layer on top. Routing, notifications, and report generation that had been hours of manual work each week. This is worth naming separately because the order matters, and we will come back to it at the end. More on that side of the work on the automation service page.
What changed
Five tools became one, and hours of daily manual data entry became minutes.
The outcome that mattered more was less visible: data entry errors from copying between systems went to zero. That is only a true statement because the copying stopped existing, not because anyone got more careful. Error rates respond to removing the step far more reliably than they respond to attention, and that is the strongest argument for consolidation over process improvement.
What we missed: the reports nobody listed
Here is the part that did not go well.
Scoping covered what each of the five tools did. It did not cover what each of them produced. Tax reporting had been one of the five, and that tool generated monthly reports as a matter of course, quietly, on a schedule nobody thought about because nobody had to. So it never came up as a requirement, and we never asked. The client did not raise it, and the honest version of that sentence is that we did not raise it either.
The first month-end after launch arrived and the reports were needed. We built the reporting in a rush, which is the worst possible condition under which to design a report, because the deadline is fixed and the thinking gets compressed into whatever fits.
The lesson generalizes past this project: a consolidation inherits every obligation the old tools were quietly meeting. When you replace a system, you take on its outputs as well as its data. So the scoping question is not only what does each tool do, but what does each tool produce, on what schedule, and who receives it. Deadline-driven outputs are the ones that hurt, because month-end does not move to accommodate a discovery made in week one of production. Seeing working software early shortens this kind of gap, which is part of why we ship in usable increments, but it does not close it. Only asking the question closes it.
The requirement that usually gets left out
On a different operations platform, one we took over rather than built, the missing requirement was accessibility.
Internal tools get scoped without it constantly, and the reasoning is always some version of “it is only staff who use this.” Staff have disabilities in the same proportion as everyone else, and an internal platform that cannot be operated by keyboard is a hiring constraint the business has imposed on itself without meaning to.
A compliance review on that platform found over 200 WCAG violations: unlabeled form inputs, missing landmark roles, contrast failures throughout the interface, no keyboard navigation. Getting it to WCAG 2.1 AA was a project in its own right rather than a round of fixes. The part that actually stuck was not the fixing, it was putting accessibility checks into the development workflow afterwards so regressions surface in code review instead of in the next audit. The standard and which rules apply to your situation are covered in the compliance post, and how we approach that work lives on the accessibility service page.
The generalizable version: retrofitting accessibility costs several times what specifying it up front costs, and internal tools are not exempt from it.
What consolidation does not fix
Consolidating tools does not fix a broken process. It makes the process explicit, which is genuinely useful and occasionally uncomfortable, because a workflow that has been living in five tools and one person’s head has to be written down before it can be built. That sometimes surfaces the fact that two departments were doing the same step differently and neither knew.
It also concentrates risk. Five tools failing independently is annoying; one platform failing takes everything with it. Backups, access control, and recovery planning matter more after consolidation, not less, and anyone selling you a platform without raising that is not finished thinking about it.
And it is a build, with the timeline a build implies. That question deserves its own answer, in how long it takes to build a website. This is also the point where the honest recommendation is sometimes to keep the five tools and fix the integration between them instead. Consolidation earns its cost when the workflow itself is the product, not when the tools are merely annoying. The custom build case rests on that distinction.
Consolidate first, then automate
The order matters more than either step.
Automating five disconnected tools automates the copying, which means you have built a faster version of the problem and made it harder to see. Consolidate first, so the data has one home and one shape, and the automation layer then has something coherent to act on. That sequence is the reason the automation in this project was worth building at all.
The tools change from company to company. The pattern does not: if a person has become the integration layer, no amount of better spreadsheets fixes it.