ERP development services sell a specification

An ERP development services engagement has a document at the centre of it. You write down what the system should do, a firm quotes against that, and from then on the document is the contract, the scope boundary, the change-order trigger and the definition of done, all at once.

The market sells this under several names. ERP software development services, custom ERP development, ERP implementation. Same shape underneath.

That document is doing more work than anybody admits, because it describes what the software should contain. It rarely describes what has to be true about the business once the software arrives. Which is how an engagement succeeds on its own terms and still leaves you worse off.

One account of it came from a CTO, describing a system built for a national parts distributor's call centre. The thing being replaced was a green screen application in use since the early nineties. A conglomerate had bought the company and wanted the legacy systems gone, and the new one compatible with its own inventory system.

By that account: "We did the job and met the specification but the project failed because the client did not plan well and order velocity went down significantly because the new inventory system was much slower than the one they had (think 1-2 seconds per product lookup in the legacy system to 20-30 seconds per lookup x tens of thousands of items per day). They ended up eating losses for several quarters in a row until the system got reverted."

A product lookup went from one or two seconds to twenty or thirty, and nothing in the specification said it must not.

The detail that should stop anyone about to sign: the same account says the sales team had warned them of exactly this problem, and that the warning was rejected. The information was in the building. Nobody with authority was obliged to act on it, because acting on it was not in scope.

The second failure mode is slower. It eats the budget rather than the business.

An operations veteran of more than thirty years, quoted by someone who worked with them, put it in one line: "The problem was we endlessly customized and adapted the ERP to how our business ran, instead of changing our processes to how the software operates. Nobody was there to say no."

That last sentence is the whole mechanism. On a time and materials engagement, every request to bend the software toward an existing habit is revenue for the firm doing the bending. The person who would have to refuse it doesn't work for you.

Levon Azevedo named the same thing from the builder's side, describing a thirteen module CRM and ERP shipped in forty five days, and was precise about its shape: "Scope creep almost never arrives as a new feature. It arrives as 'can we just add one field.'" What made that timeline possible, by the same account, was freezing the data model in week one. The interface stayed ugly until month three.

Freezing the data model is somebody being allowed to say no, written down as a technical decision.

The instinctive correction to a failed ERP project is a bigger one. The accounts point the other way.

Devesh Shukla, who describes working as a consultant across these projects, wrote: "A $5M Oracle Retail project often delivers LESS business value than a $50K focused AI automation. Why? Scope creep. Customizations. Change orders. Big systems breed big inefficiency. I saw this on every single project."

Team size behaves the same way. Jakub Skalecki reported starting a fairly complex ERP as a solo developer and having it in use in a laboratory two months later, adding that "Another company with 5+ devs couldn't build and deploy it in 2 years." One person is not better than five. What one person has is no coordination cost and no incentive to expand the scope.

Owners are doing versions of this themselves. A cabinet shop owner reported replacing ERP, CRM and MRP, and building an automated push pull stop system for under $5,000 that would normally run over $100,000. Brian Barber reported building a custom ERP covering warehouse management, container tracking, auto-invoicing, a B2B portal and role-based dashboards in six months, and replacing $35,000 a year of software with it.

It would be convenient to conclude that the tooling has removed the problem. The evidence does not support that, and the honest counterweight is easy to find.

One person building a custom ERP with an AI coding tool wrote to its maker asking for help. Two months of work had failed, they said, and they wanted to learn how to improve. Six months and a working system, in the accounts above, is the good outcome. It isn't the typical one.

What has changed is narrower and it is worth being exact about. The cost of building a small, specific thing has fallen far enough that the small specific thing is now a real alternative to the large general one. That is the comparison the consultant above is making, $50,000 of focused automation against $5,000,000 of retail ERP.

It also changes who holds the scope. When a change costs a change order, every request is a negotiation with a supplier. When the person who feels the problem can describe it and see the result the same day, the request stops being a purchase, and the answer to can we just add one field can be no without anyone losing money by saying it.

The pattern that survives all of this is unglamorous. Leave the systems that already hold your records where they are. Put something on the work between them, and buy the smallest thing that removes a real cost. It's the same argument as any other workflow that only exists between two systems, and it's why the alternative to an ERP programme is usually not another ERP programme.

These follow from the accounts above rather than from a procurement template.

1. What in this contract is measured in seconds? The reverted project met every functional requirement. It failed on lookup time, and speed was nobody's deliverable.
2. Who is allowed to say no to a customisation, and do they work for you? If refusing a request costs your supplier revenue, they will not be the one refusing it.
3. When does the data model freeze? Ask for a date. The one fast delivery described above froze it in week one and let the interface stay ugly for months.
4. What happens to the people who already know the answer? In the reverted project the sales team had warned about the exact failure and were overruled. Ask who is obliged to listen, and what happens when they are ignored.
5. What is the smallest version that removes a real cost? If nobody can describe it, the scope is not understood well enough to price, and a change order is already inevitable.

And one after signing: agree now what reverting looks like. One of the accounts above ended in a revert after several quarters of losses, which is the expensive way to discover that nobody had planned for it.