The most dangerous moment in a traditional ERP project is UAT (User Acceptance Testing). That's when the client sits down with the system for the first time after a long build phase, and discovers it was built to the wrong target. The spec was accurate. The developers delivered what was written. And the thing that was written turns out not to be what anyone actually needed, because nobody knew that until they watched a real workflow run in real software.
We've walked into that situation as a rescue engagement more than once. The prior team wasn't incompetent. The spec wasn't obviously wrong. The process just doesn't surface the gap between "what we asked for" and "what we need" until something is working. Iterative delivery is how you surface that gap at week four instead of month eight.
The Pattern
Every project we run follows the same cycle, repeated until the system is done.
- Research the actual workflows. Not the documented ones. The ones people actually run. These are often different, and the difference matters.
- Design against what we learned. Not a hundred-page specification. Enough design to know what we're building next.
- Build to "gears turning." A working end-to-end flow on real-shape data. Not polished. Not complete. Working.
- Bring the client back in. Walk through what exists. Watch where they hesitate, where they correct us, where they say "oh, we actually do it this way."
- Adjust and build more. Fix what the walkthrough revealed. Extend into the next piece. Repeat.
The cycle is not exotic. Most experienced developers work this way instinctively on smaller projects. The discipline is applying it deliberately on an ERP project, where the temptation is to disappear into a long build and surface with something finished.
What "Gears Turning" Actually Means
"Gears turning" is the minimum working state worth showing a client. It means a specific workflow runs end-to-end, on data shaped like their real data, in a real Odoo instance. It does not mean every edge case is handled. It does not mean the UI is polished. It does not mean related workflows are complete.
A concrete example. If we are building a custom receiving flow for a distribution client, "gears turning" might look like this: a purchase order exists, a warehouse user opens the receipt, the system applies the custom receiving logic, inventory updates, and the correct accounting move is generated. That's it. No error handling for partial receipts yet. No custom report. No integration with the downstream pick flow. Those come in the next cycle or the one after.
What the client sees at this stage is enough to confirm: is the logic correct? Is the data modeled the right way? Does this match how the receiving team actually works, or did we misunderstand something in the discovery session?
Showing something incomplete is uncomfortable for consultants trained to deliver polished work. But a working rough cut surfaces misunderstandings that a polished finished system buries. The sooner you know you built to the wrong assumption, the cheaper the fix.
Why the Alternative Fails
Long spec-then-build cycles fail for a specific reason: the client cannot fully imagine a system they haven't seen. They can describe their workflows. They can review a process diagram. They can sign off on a requirements document. None of that is the same as watching the workflow run in software and immediately seeing the three things that aren't quite right.
The longer the build phase before the first client walkthrough, the more that gap compounds. A six-month build followed by UAT is not a project with one feedback point. It's a project with six months of accumulated misunderstanding waiting to be discovered at the worst possible time.
We've audited codebases where entire custom modules were built around a workflow the client had actually changed eight months earlier. The team was heads-down building. Nobody checked. The work wasn't salvageable; it had to be rebuilt. The cost wasn't just the rework. It was the missed go-live date and the damage to the client's confidence in the project.
Iterative delivery doesn't prevent mistakes. It prevents expensive mistakes. The same misunderstanding caught at week four costs a fraction of what it costs at week twenty.
Two Outcomes Clients Actually Care About
When clients tell us what went wrong on a prior ERP project, they almost always describe one of two things: the system didn't fit how they actually work, or they were blindsided at go-live by problems nobody warned them about. Iterative delivery addresses both directly.
No surprises. When a client has seen every significant milestone across the project, go-live is not a reveal. They've already seen the receiving flow, the fulfillment flow, the custom pricing logic. They've already pushed back on the parts that were wrong. By the time we're in final testing, there is nothing in the system they haven't already walked through. That's not an accident; it's the point of the cycle.
What they need, not what they originally asked for. This is the subtler outcome and the more important one. What a client describes in a discovery session is their best understanding of what they need before they've seen the system. Once they watch a workflow run in software, they learn things about their own process they couldn't have known beforehand. Requirements change. They always do. The question is whether your delivery model treats that as a problem or as the expected product of a working process.
Iterative delivery treats it as expected. Each cycle is an opportunity to incorporate what the client learned from the last one. The target gets clearer over time because the client is actively involved in clarifying it, not because the spec was perfect at the start.
Making It Work in Practice
Keep cycles short enough to be useful
A cycle that runs six weeks is too long. By the time you surface a misunderstanding, it's been embedded in three weeks of downstream code. A useful cycle is one to two weeks for active build phases. Some discovery and design work runs longer, but the "build to gears turning, show the client" part should be frequent enough that no significant piece of work goes more than two weeks without a client touchpoint.
Show what's working; be honest about what isn't
Don't hide incomplete work, but be clear about what you're showing and what's still ahead. "Here is the receiving flow. The partial-receipt handling and the downstream pick integration aren't built yet; we're confirming the core logic before we layer those in" is a straightforward framing. Clients handle incompleteness well when they understand the plan. They handle surprises poorly.
The discipline is showing the right slice: complete enough to verify the core assumption, not so incomplete that the client can't evaluate it.
Keep the client engaged, not just informed
Iterative delivery requires a client who shows up. Status updates are not the same thing as working sessions. We ask clients to bring the actual users to the working sessions, not just the project sponsor. The receiving manager needs to see the receiving flow. The accounting lead needs to see the journal entries. The further the feedback is from the person who will actually use the system, the less useful the feedback is.
Some clients resist this, usually because their users are busy. We push back on it gently. The cost of pulling a warehouse manager into a one-hour working session at week four is nothing compared to the cost of finding out at week twenty that the flow doesn't match how the warehouse actually works.
Handle change requests cleanly
Change requests are not emergencies in an iterative model. They're information. When a client sees a working cycle and says "actually, we need it to work this way instead," that is the system working as designed. We note the change, assess the scope, fold it into the next cycle or schedule it explicitly if it's larger, and keep moving.
What iterative delivery doesn't do is let changes accumulate silently. Every change gets acknowledged, scoped at a high level, and scheduled. The client always knows what's in the current cycle and what's queued for the next one. That's how you avoid the other version of the late-project surprise: a client who added twenty "small" changes over four months and expects them all to be done by the original go-live date.
If you've been quoted a fixed-bid ERP project with a three-month build phase and no client checkpoints until UAT, that's worth a second look. It's not necessarily a bad project, but the delivery model puts all the discovery risk at the end, where it's most expensive to resolve. A real conversation about what an iterative engagement looks like instead costs nothing. DimeSoft has run Odoo projects this way across distribution, manufacturing, and e-commerce clients since well before "agile" was a word anyone used in ERP sales. Reach out and we'll walk through what it would look like on your project specifically.