You signed the contract. You paid for the implementation. You went live. Then your business changed, the way every business changes, and you called the vendor.
"We need a new approval rule."
"We will scope a change order. Estimated cost: $12,000. Timeline: 4 weeks."
That is not a bug. That is the business model.
How the change order machine works
Every traditional ERP is built as application code. The procurement workflow is code. The approval logic is code. The production stage definitions are code. The dispatch rules are code.
When you need a change, someone has to modify the code. That means a developer. Developers cost money. They need to understand the codebase, write the change, test it, deploy it. Even simple changes take days because of the overhead of not breaking something else.
The vendor is not being greedy (well, not just being greedy). The architecture genuinely requires developer time for every change. The business model follows the architecture: you pay per change because changes require engineering work.
Over time, this creates a dependency loop:
1. You need the vendor because only they understand the codebase.
2. They charge per change because changes are engineering work.
3. You accumulate changes. Each one adds complexity.
4. The codebase becomes more fragile. Changes take longer.
5. Costs go up. Timelines stretch.
6. Switching costs are too high to leave.
This is vendor lock-in. Not through a contract clause. Through architecture.
The annual math
A mid-market manufacturer on Epicor or Plex typically requests 8 to 15 changes per year. New approval rules, new reports, new workflows, new user roles, new integrations.
At $8,000 to $20,000 per change order, that is $64,000 to $300,000 per year in post-deployment customization. On top of the $25,000 to $40,000 annual maintenance fee. On top of the $150,000 to $300,000 you already paid for the initial deployment.
Five-year total cost of ownership for a mid-market ERP: $500,000 to $1,200,000. And you still do not have everything you need.
Why it does not have to work this way
The change order model exists because business rules are stored in code. If you move business rules out of code and into your SG Schema, the change order disappears.
In SimpleGrid, business rules live in tables. Not application code. Tables.
Need a new approval rule? Add a row. Need to change a threshold? Update a cell. Need a new permission? Add a row. Need a new automatic trigger? Add a row.
The SG Engine reads these tables and enforces them in real time. No developer involvement. No deployment. No downtime. No change order.
Here is a real comparison:
The question to ask your current vendor
"Show me every business rule the system currently enforces, in one place."
If the answer requires a developer, a code review, or a consultant, your rules are in the wrong place. And you will pay every time they need to change.
SimpleGrid stores every rule in a table. Zero change orders. Zero developer dependency. Zero annual surprise.