Amnesia at Scale: The Real Reason Your Company Keeps Building the Same Software
Photo: developer working late at multiple monitors office, via images.stockcake.com
Somewhere in your organization right now, a team is building a customer database. It is not the first one. If your company has scaled past fifty employees, it is probably the fourth.
The pattern is so consistent across American mid-market companies that it borders on a law of nature: every growing business eventually rebuilds its own CRM, its own billing engine, and its own workflow tracker. Each version is commissioned with genuine enthusiasm, delivered with quiet compromise, and abandoned without a proper burial. Then, eighteen months later, someone proposes building a better one.
The Three Tools Every Company Builds
Ask a founder what software their business runs on and they'll name their vendors. Ask a department head and you'll get a different answer. That gap is where the duplication lives.
The first rebuild usually starts in sales. A spreadsheet becomes a tracker, the tracker becomes a pipeline tool, and the pipeline tool becomes a half-finished CRM with custom fields nobody asked for. The second lives in finance: an invoicing workaround that metastasizes into a billing system with its own logic, its own edge cases, and its own undocumented rules. The third emerges wherever coordination pain peaks — project management, ticketing, approvals — because the commercial tools never quite fit how the work actually flows.
None of these projects begins with hubris. They begin with a legitimate gap. The commercial tool was too rigid, too expensive, or too slow to configure. So a capable person with a database solved a real problem. That's not the failure. The failure is what happens next.
Organizational Amnesia, Documented in Git History
Here is the uncomfortable truth about the fourth system problem: it is rarely a technology failure. It is a memory failure.
By the time a company contemplates its fourth internal build, the reasons the first three were abandoned have evaporated. People have changed roles. The original constraints — the compliance requirement, the edge-case customer, the integration that broke — exist only in the heads of people who have since moved on or moved out. What remains is a vague collective feeling that "the last one didn't work," which is not a constraint. It's a mood.
This amnesia is compounded by how internal tools die. Nobody writes a post-mortem for a retired spreadsheet. There's no decommissioning ceremony, no archived decision record. The institutional knowledge that would prevent a rebuild — here is exactly why version two couldn't handle multi-entity billing — is the first casualty of any reorganization.
The result is that each new system is proposed in an information vacuum, and each vacuum gets filled with optimism. Optimism is a terrible architect.
Why Each Version Gets Slightly Worse
Counterintuitively, the rebuilds don't improve with practice. They degrade, and the mechanism is straightforward.
The first internal tool is built by someone who deeply understands the problem because they live it daily. The second is built under more pressure, with more stakeholders, and by someone with less direct exposure to the work. By the third iteration, the builder is often several steps removed from the actual user, translating requirements through layers of management. The tool encodes someone's understanding of the workflow rather than the workflow itself.
Meanwhile, the accumulated workarounds from previous versions — the tribal knowledge, the manual reconciliations, the "oh, don't touch that field" rules — don't transfer. They have to be rediscovered, painfully, in production.
A Framework for Breaking the Cycle
Before approving build number four, put three questions in writing and require written answers.
First: What killed its predecessors? Not vibes — specifics. Interview the people who maintained the last version and document, in a permanent artifact, the three forces that made it unworkable. If those forces haven't changed, the new build inherits the same fate.
Second: Who owns the gap today? Internal tools rot in the space between departments. If no single named person owns the problem the tool solves, the tool will drift into orphanhood the moment its champion changes roles.
Third: What is the honest build-versus-buy threshold? Most companies discover that their genuine differentiator justifies building one internal system at most. The other two categories should be configured, not constructed. Writing down which category each candidate falls into — before the sunk-cost momentum starts — is the cheapest governance decision an executive team can make.
The Discipline of Remembering
The companies that escape this cycle don't have better engineers. They have better memories. They treat every internal tool retirement as a documented event, every build decision as a recorded rationale, and every "we should just build our own" moment as a prompt to reread the last three.
The fourth system problem is not really about systems. It is about whether an organization can learn from its own history faster than it can forget it. For most growing businesses, that race is closer than anyone would like to admit — and the scoreboard is sitting, half-finished, in a repo nobody has opened since 2023.
