There is a version of an ERP project that never ends. It starts with a reasonable estimate, a friendly kickoff, and an hourly rate. A year later the invoices are still arriving, the go-live date has moved three times, and nobody can say what done means anymore. If you have sat through one of these, you already know why we refuse to sell them.
We work fixed scope, fixed price. Every implementation we take on is quoted after a scoping phase, delivered against a written scope, and priced as a number — not a rate. When a prospect asks for open-ended time-and-materials instead, we say no. That is not us being difficult. It is about who carries the risk, and we think the answer should be us.
Why open-ended T&M projects drift
Time-and-materials sounds fair on paper: you pay for exactly the work done. In practice it removes the one force that keeps an ERP project convergent — a shared, binding definition of done. An ERP touches every department in a company. The moment scope is open, every department discovers something it would also like, every ambiguity gets resolved by doing more, and every extra hour is billable. None of this requires bad faith. It is simply what the structure rewards.
It also quietly moves all estimation risk onto the client. If the vendor underestimated the accounting migration, the client pays for the miss, hour by hour. The party with the least information about how long ERP work takes ends up insuring the party with the most. We think that is backwards. Under a fixed price, a wrong estimate is our loss to absorb — which is exactly why we estimate carefully, and why we insist on a real scoping phase before we quote anything.
What a real scoping phase produces
Scoping is not a sales call with a slide deck. It is structured work with concrete deliverables, and everything in the eventual quote traces back to them:
- A module list — which Odoo Community and OCA modules cover each business process out of the box, and where a gap genuinely requires custom development. We are Community-first and OCA-first on principle: less custom code means less to maintain and less to break at upgrade time.
- A data inventory — which legacy systems hold data, what volumes are involved, which objects migrate, and which reconciliation reports will prove the migration is complete.
- Custom depth, per gap — whether the answer is configuration, an extension of an existing module, or a new module. Anything we build is developed to module grade and versioned in Git, so it survives upgrades and audits.
- A cutover plan — dry-run migrations before the real one, reconciliation checks after it, and a rollback plan we hope never to use.
- Roles and training — who touches which screens, and the role-based training that maps to that, so adoption is planned rather than hoped for.
The output is a scope document precise enough to put a fixed number under. That number covers the listed modules, the listed data, the listed customizations, and the listed training — nothing vaguer than that. If our estimate turns out wrong after signing, that is our problem, not yours.
Change requests without hourly creep
Fixed scope does not mean your business freezes. Requirements change; that is normal. What changes is how change enters the project. A new requirement becomes a change request: described in writing, checked against the scope document, quoted as its own fixed price, and accepted or declined before any work starts. There is no hourly drip and no surprise line on next month's invoice.
The scope document is what makes this fair in both directions. If something we delivered does not work as scoped, that is a defect and we fix it at our cost. If it was never in the scope, it is a change request with its own price. Either way, the boundary gets argued from a written document, not from memory in a status meeting.
The same philosophy carries past go-live. Support runs on tiered SLAs — 24-hour, 4-hour, or 1-hour response depending on the tier you choose — backups are restore-tested rather than assumed, and upgrades are tested against your customizations before they touch production. Defined commitments, everywhere, because open-ended is where trust erodes.
Saying no to open-ended work costs us some deals, and we are at peace with that. The projects we do take on finish, land on a number both sides agreed to, and leave behind a system someone can actually maintain. If you are weighing an ERP project and want to see how a scoping phase would frame yours, our implementation services page walks through the process step by step.