The System of Record Should Be Local
I have come to think that, for supply chain, most companies should stop buying broad systems of record and start building them locally. I am speaking of the software that records orders, receipts, stock movements, invoices, approvals, and the clerical aftermath of ordinary operations. These systems are critical, but their value is bounded. They are ledgers with workflows. The market still prices them, presents them, and governs them as if they were the crown jewels of the firm. That mistake has become very expensive.
In Introduction to Supply Chain, especially Chapters 5 and 6, I drew a line between software that keeps the paper trail and software that makes decisions. That distinction matters here. Once we look at a record system without the usual theater, much of the mystique vanishes. A system of record should be reliable, auditable, and rather boring. It should not pretend to think. It should remember facts, enforce a few workflows, and stay out of the way.
The hidden tax of packaged ledgers
A record system reaches commercial maturity quickly. Once it can faithfully handle purchasing, sales, inventory, invoicing, and a few adjacent workflows, the extra value of making it broader is slight. Vendors know this perfectly well. Their answer has been the same for decades: add another entity, another screen, another module, another configuration page. Sell the next increment to the installed base. Over time, the product becomes the sediment of countless customer requests, many sensible in isolation and absurd in the aggregate. The result is a feature mastodon whose complexity keeps rising even though the underlying job has barely changed.
The academic literature has described the same problem in calmer language for years. Strong and Volkoff observed that packaged enterprise systems are designed for generic rather than specific requirements and therefore tend to be an imperfect fit in any concrete organization. A more recent study on ERP customization makes the trade-off explicit: tailoring can improve functionality and user satisfaction, yet it also increases implementation cost, complexity, and the expense of later upgrades. A 2025 review of ERP misfits reaches an equally sobering conclusion: implementation failure rates remain high, the misalignment between standardized processes and local workflows persists, and no widely adopted industry practice has emerged to resolve these mismatches cleanly.
This tax is not confined to license fees. Panorama’s 2025 ERP benchmark reports a median project cost of 450,000 USD and a median timeline of nine months. Among projects that went over budget, the most common reason was the unexpected need for additional technology. Among projects that ran late, data issues were the main culprit. The same report notes that many ERP implementations still fail to remove organizational silos. This is the pattern I keep seeing: the suite does not abolish complexity; it redistributes it into integration, migration, governance, and elaborate workarounds.
The underlying data models tell the same story. Microsoft’s documentation for Dynamics explains that a simple business concept such as a customer may be scattered across several normalized tables, which is precisely why data entities exist as denormalized abstractions. Oracle’s JD Edwards documentation exposes long catalogues of tables by type and by module. ERPRef, a third-party schema catalogue, lists 1,687 tables for SAP Business One 9.0 and 5,097 for JD Edwards 9.20; on that same catalogue, the A/R invoice table in SAP Business One 9.3 is shown with 424 columns. A given company will use only a sliver of this breadth, yet it still pays for the breadth in permissions, mappings, integrations, training, and upgrades.
There is a second tax, and it is often the more damaging one. William Ocasio’s attention-based view of the firm starts from a plain observation: what firms do depends on how the attention of decision-makers is channeled. A sprawling record system consumes that attention as surely as it consumes cash. Years spent on implementations, cleanups, migrations, redesigns, bolt-ons, and upgrades are years in which senior management is absorbed by the mechanics of clerical infrastructure. I have argued elsewhere that when records and reports consume most of the software budget, they also consume most of the executive bandwidth, leaving little room for the software that might actually improve decisions.
Why bespoke stopped being difficult
The remarkable part is that the technical case for bespoke record systems ceased to be exotic quite a while ago. PostgreSQL has nearly forty years of active development behind it and has been ACID compliant since 2001. ASP.NET Core is free, open source, and cross-platform. Entity Framework Core supports change tracking, updates, and schema migrations across multiple databases. Django ships with built-in protections against common web attacks. When the plumbing for transactional software has become this mature, building a narrow internal ledger is no longer an act of bravado.
There is even a revealing detail in the Django documentation. Its automatic admin interface is recommended for an organization’s internal management tool, not for a public front end. That small remark captures the whole affair. The industry has standardized the back-office skeleton of CRUD software so thoroughly that major frameworks now ship it out of the box. What remains difficult is not the plumbing. What remains difficult is deciding which entities, states, and workflows truly matter to your company and which ones are only there because some vendor has spent twenty years collecting quirks from a market segment.
This is where bespoke wins decisively. The advantage is not virtuosity in code. The advantage is semantic exactness. The entities can correspond to the company as it actually operates: its product hierarchy, its purchasing exceptions, its receipt statuses, its approval rules, its return motives, its quality holds, its odd but useful distinctions that no generic suite should be expected to understand. A small local codebase can remain intelligible. More importantly, the company keeps ownership of the operating knowledge embodied in that code. The software reflects the business; the business no longer has to inherit the accumulated compromises of a vendor’s entire customer base.
What coding agents changed
What changed in 2025 is not the database, nor the browser, nor the web stack. What changed is the cost of producing the code. In January 2025, Anthropic reported 49 percent on SWE-bench Verified for an upgraded Claude 3.5 Sonnet agent. By August, Claude Opus 4.1 reached 74.5 percent. The SWE-bench team later noted that mini-SWE-agent reached 65 percent on the same verified subset in a bare-bones setup. OpenAI, for its part, released Codex as a cloud software agent that can work on many tasks in parallel, run tests and linters in isolated environments, and propose changes for review; in a separate internal product experiment, OpenAI says Codex wrote the entirety of a million-line codebase that was built in about one-tenth of the time hand-coding would have required.
This does not mean that agents make every engineer faster on every codebase. METR’s randomized trial on experienced open-source developers found that early-2025 AI tools slowed them by 19 percent when they worked on their own repositories. I take that result seriously. Yet it does not describe the same problem. Maintaining a mature public codebase with exacting standards and years of tacit context is not the same task as drafting a receiving workflow, a supplier portal, a stock-adjustment back office, or a returns screen for an internal team. For the latter, the requirements are local, the acceptance criteria are concrete, and the architecture is ordinary. METR’s separate time-horizon work also reports that the length of software tasks frontier agents can complete with 50 percent reliability has been doubling at about seven months. That is exactly the sort of trend that matters when the work is narrow and well-scoped.
This is why even an ordinary manufacturer, distributor, or retailer can now sensibly own far more of its transactional software than before. Such a company does not need to become a software vendor. It needs a process owner who knows the business, a technically literate lead, a small codebase, a test suite, and the discipline to keep the scope narrow. Coding agents reduce the amount of manual implementation needed for the dull parts, which happen to be most of the parts in record systems. Meanwhile, the mature open-source stack does the rest. The combination is powerful precisely because record systems are so unglamorous. They are mostly forms, tables, validations, permissions, workflows, and integrations. That is where the tooling is strongest.
I would still spare the domains where the vendor’s main value lies in keeping up with statutory change. Those are real exceptions. Outside them, especially in supply chain, the default should reverse. For purchase flows, receiving, returns, quality holds, supplier collaboration, master-data stewardship, and similar transactional domains, broad packaged software has become the expensive way to obtain a mediocre fit. The bespoke alternative is no longer reserved for technology companies. It is now within reach of ordinary firms, provided they are willing to own a modest amount of code and to refuse the temptation of turning that codebase into a grand platform.
The case is no longer sentimental and it is no longer futuristic. Broad packaged ledgers are generic by construction, misfit by habit, and inflationary in both cost and attention. The tools for building narrow replacements have been mature for years. Coding agents have now compressed the last part that used to keep many companies from acting, namely the sheer amount of routine coding. For supply chain systems of record, the burden of proof has flipped. A company should begin by asking why this system should be bought at all.
