Code Agency
3 min read

Why every Odoo project starts with a fit-gap analysis (and why we enforce it)

The cheapest moment to discover a problem is before anyone writes code. What a fit-gap analysis actually is, what it produces, and why Code Agency won't scope an implementation without one.

Ask a failed ERP project what went wrong and you'll rarely hear "the software was bad." You'll hear: we discovered too late that our process didn't fit, the budget doubled halfway, nobody agreed on what 'done' meant. All three are the same root cause — the project was scoped by guessing.

A fit-gap analysis replaces the guessing. It's the reason we won't quote an implementation without one, and it applies just as much to complex custom applications as it does to Odoo.

What a fit-gap analysis actually is

We sit with the people who do the work and management — and walk every process the system must support: sales, purchasing, warehouse, invoicing, the weird exception path that only John or Jane knows about. For each step we answer one question:

  • Fit — standard Odoo does this. Configure it, done.
  • Gap — the standard doesn't match. Now decide: adapt the process to the standard, or adapt the software to the process.

That decision is where implementations are won or lost. Every gap closed by customisation costs money now and maintenance forever; every gap closed by process change costs some habit-breaking now and nothing later. A good analysis challenges you on each one: is this gap really your competitive edge, or just "how we've always done it"?

What you get out of it

The deliverable is a document you own (like everything we build — paid is yours):

  1. A process map of how your business actually runs — often the first one that exists.
  2. The fit list: everything standard Odoo covers out of the box.
  3. The gap list: each gap with its resolution — process change, configuration, or custom development.
  4. An accurate estimate in hours for the whole implementation, built from those decisions — not a day rate and a shrug.

That last point is why we enforce this. Without a fit-gap analysis, any estimate is fiction, and honest fiction is still fiction. With one, the estimate is an addition of known parts — and the timesheets you see during the project map back to it, to the minute.

"Can't we skip it? We know our processes."

Every company knows its processes the way everyone knows their own house — until they draw a floor plan. In twenty years we have never run a fit-gap analysis that surfaced nothing: the undocumented discount rule, the spreadsheet that is secretly the real inventory system, the approval step that exists only in one person's inbox.

Found in analysis, each of those is a line in a document. Found in week eleven of the build, each is a change order, a delay and a difficult conversation. The analysis costs a fraction of a single one of those surprises.

It works for custom software too

The same discipline applies beyond ERP. Every custom application we build starts the same way: map the real process, separate must-have from nice-to-have, decide build-vs-configure per gap, estimate in hours from the result. Blueprint first — scope, then build.

That's the whole philosophy: we'd rather lose a week planning than lose a quarter rebuilding. Start with the analysis; everything after it gets easier, cheaper and calmer.

Get the next one in your inbox

New articles, videos and the occasional engineering note — a short mail when there’s something worth reading, nothing else.