Adding an Industry to an ERP: a Recipe, Not a Kitchen

Short answer. A trained chef already knows knife work, heat, and timing. Hand them a recipe for a dish they have never cooked and they will make it tonight, because the recipe carries what is specific and the chef carries what is general. That split is the whole argument for how industry verticals should work in an AI-native ERP: the model is the chef, the module manifest is the recipe, and the shared database is the kitchen. Adding an industry means writing one more recipe, not sending the chef back to culinary school. Disclosure: we build ERPClaw and this is how it is built, so weigh the framing accordingly.

What conventional ERP does instead

Ask a traditional ERP vendor for a vertical they do not have and you are asking for a second kitchen. New tables, new screens, new business logic, new integration surface, and a services engagement to connect it to the accounting that already exists. The work is real, which is why it is quoted in months rather than weeks.

The comparators usually cited for a mid-market implementation are 15.5 months and around $450,000. Both are reported industry survey medians from Panorama’s 2024 research, not controlled measurements of anything, and they should be read as the shape of the market rather than a benchmark. The direction is what matters: a new vertical in that world is a project, not a configuration.

What the recipe carries

In an AI-native system the split falls differently, because the general knowledge lives in the model and the specific knowledge lives in a manifest.

The chef, meaning the model, already knows how double entry works, what a debit is, why a ledger balances, how a receivable ages, and what a period close means. None of that has to be taught per industry, because none of it changes per industry. A tattoo parlour and a haulage firm keep books the same way.

The recipe, meaning the manifest, carries what is genuinely specific: the entities this industry has that others do not, the actions its operators actually perform, and the handful of business preferences that differ from shop to shop.

The kitchen, meaning the shared database with one writer per table, is what makes the recipe safe to run. A new module reads what it needs and writes only its own tables, so a new vertical cannot corrupt the sales ledger by accident. That ownership rule gets its own treatment in one person holds the pen, and the reason an AI needs deterministic code underneath it is in why an AI cannot be your accounting system on its own.

The instance, with the number that surprised us

We generated a module for a tattoo parlour. It came out small, a handful of tables and the actions an operator of one actually performs, and its whole generated test suite passed.

The number worth reporting is not any of those. Across three generated modules, grooming, tattoo, and storage, there were 19 human decisions in total, and every single one was a business preference rather than an accounting decision. How long a deposit is held before it is forfeit. Whether a no-show is billed. Whether a storage unit is prorated on exit.

Nobody was asked how double entry works. Nobody was asked which account a deposit posts to, or whether the books should balance. Those questions never surfaced, because they were never industry-specific in the first place. That is the claim in its most concrete form: the decisions that remain are the ones a business owner should be making, and they are the only ones left.

Where the analogy breaks, and it does

Three limits worth stating plainly, because an analogy that survives every objection is usually hiding something.

A recipe assumes the dish is cookable with the equipment present. A vertical that needs something genuinely absent from the kitchen, a new regulatory filing regime, a physical device integration, a compliance certification, is not a manifest. It is kitchen work, and it costs what kitchen work costs.

A fully passing suite is a statement about the tests, not about the world. It says the generated module does what its specification described. Whether the specification described the industry correctly is a separate question, and the only honest answer is that a practitioner has to look.

Three modules is three. It is enough to show the pattern holds and not enough to characterise its limits. We would rather say that than round it up into a trend.

Why this is a reuse argument, not a configuration argument

The objection we hear most is that this is just configuration with better marketing. It is a fair challenge and worth answering directly.

Configuration implies switches on a fixed system: the entities exist, and you are turning things on. What happens here is that a module which did not exist is generated, with its own tables and its own actions, against an interface contract the rest of the system already honours. What gets reused is the accounting core and the contract. What varies is the manifest.

Whether that deserves the word reuse or the word generation is a fair argument to have. The distinction that survives either label is the one that matters commercially: conventional ERP answers a new industry by building a second system and connecting it. This answers it by writing one more recipe for a chef who can already cook.

Where this came from

This is one of the explanations we developed for the IEEE International Conference on Information Reuse and Integration in July 2026, where the reuse question was put to us directly by an audience whose entire field is reuse. It survived that room, which is a better test than surviving our own.