Odoo Partner Capacity: How to Scale Delivery

Capacity is not headcount. A partner’s real delivery capacity is how much work can move through the few people who can finish the hard parts without help. Most agencies that feel short of people are short of standards, written decisions and a separate support lane — and hiring into that makes it worse.

Why headcount is the wrong number

Ask an Odoo practice how much capacity it has and you usually get a team size. It is the wrong answer, because the team is not interchangeable. In most practices there are two or three people who can take an unfamiliar requirement, decide how it should work in Odoo, and finish it without asking anyone. Everyone else needs some part of that decided for them.

So the real number is narrower: how much work can pass through those few people per week, including the time they spend unblocking everyone else. That is why adding a developer sometimes reduces throughput for a month. The new person consumes the scarce resource before they add to it, and nobody plans for that.

This post is about the delivery side of running an Odoo practice — the capacity itself. If what you actually need is the commercial arrangement with someone who delivers under your brand, the white label partner post covers ownership, estimates, escalation and exit, and this one deliberately does not repeat it. We do this work on the other side of that transaction and we also run Odoo support and maintenance for other people’s clients, so the patterns below come from both chairs.

The four places capacity actually leaks

Before adding anyone, it is worth finding out where the week goes. In practices we have worked alongside, the same four leaks account for most of it.

One person is the only one who can do the hard part

Accounting localisation, a gnarly inventory valuation question, the upgrade of a heavily customised module — there is usually exactly one person who can do each. The queue behind them is invisible on a project plan because the work is technically assigned to someone else, who is waiting. When that person takes leave, the plan is fiction.

Support eats the delivery week

This is the biggest one and the least measured. Live clients ask questions. Those questions arrive at developers, mid-task, and get answered because they are quick. Nobody logs them, nobody bills most of them, and at the end of the week a developer who was supposedly on a project delivered half of it. A practice that has not separated its support lane from its delivery lane does not know its own capacity, and no amount of hiring will reveal it.

Context switching across too many live clients

Odoo work carries heavy context: this client’s chart of accounts, that client’s custom module, the other one’s warehouse rules. Reloading that context costs real time, and a developer split across four live clients in a week spends a meaningful part of it just getting back to where they were. Three focused clients will often out-deliver five shared ones.

Estimates written by someone who will not do the work

When the person who sold the work is not the person who delivers it, the estimate becomes a wish. The overrun then comes out of the capacity you thought you had for something else, which is why practices that feel permanently behind are usually not slow — they are optimistically scoped. How Odoo implementations go wrong covers the client-side view of the same problem.

What to fix before you add people

Four things, roughly in this order, and none of them requires recruitment.

Standardise the repeatable work. Every practice does the same things over and over — a new company setup, a payment integration, a report layout, a data import. If each one is done from scratch by whoever picks it up, you are paying senior time for solved problems. Write the pattern down once, badly, and improve it. A mediocre documented pattern beats an excellent undocumented one, because the mediocre one can be handed to someone junior.

Write the decisions down, not just the code. The expensive knowledge in an Odoo practice is not how to write Python. It is why this client’s stock is valued the way it is and what will break if you change it. That lives in one person’s head and leaves when they do. A short decision record per client, kept honestly, is the cheapest capacity you will ever buy.

Separate the support lane. Put named hours and a named person on support, route client questions there rather than to whoever answers first, and let developers finish things. The point is not to be unhelpful; it is to make the cost of support visible so it can be staffed and charged for rather than absorbed.

Make review a habit rather than an event. Work reviewed early by one of your scarce people is cheaper than work reviewed late, and it is how juniors become people who can finish things unaided — which is the only route to more capacity that compounds.

Three ways to add capacity, and what each costs you

Once the leaks are fixed, the choice is real. All three work and all three cost something that is not money.

Hire. Highest ceiling, slowest payback. An Odoo developer takes months to become independently useful, and during those months they consume your scarce senior time. This is the right answer when your pipeline is reliable rather than lumpy, because the cost is fixed and the pipeline is what has to carry it.

Subcontract. Fastest to start, and the cost is coordination. Someone on your side has to own the brief, the review and the client relationship, and if nobody does, quality becomes a surprise. Works well for a defined piece of work with a clear boundary; works badly as a permanent substitute for a team, which we will come back to.

Embed capacity. A developer or two working inside your process, to your standards, for a period. More expensive per hour than a fixed-scope project and usually cheaper in total when the work is continuous, because nobody is re-briefing every two weeks. This is what most agencies actually want when they ask about subcontracting, and it is worth naming the difference before agreeing terms. The white label post sets out which of the three to put in a contract.

Capacity problem or scoping problem?

This is the question worth asking before spending anything, because the symptoms are identical. Three tests we use.

Look at where time went versus where it was estimated, on the last five projects. If the overruns cluster in discovery and requirement changes, you have a scoping problem and more people will burn faster. If they cluster in build on well-understood work, that is genuine capacity.

Count how much of last month was unplanned. If a third of the week is arriving unannounced, the fix is a support lane, not recruitment.

Ask what proportion of your work is genuinely bespoke. Practices that feel permanently stretched often discover that most of what they build is a variation on something they have built before, and that the variation exists because nobody decided on a standard. That is a product problem wearing a staffing costume. Where AI helps here is unglamorous and real: AI inside Odoo and custom agents can take first-line questions and routine data work off the delivery team, which buys back the support hours directly.

When we would tell you to hire instead

If Odoo is becoming central to your business rather than an occasional request, bring the capability in-house. A practice whose core offering depends permanently on someone else’s developers has a strategic problem that no commercial arrangement fixes, and we would rather say that at the start than be the reason you noticed it three years in. It costs us the work and it is the right advice.

We will also turn down engagements where we think the estimate you have already given your client is wrong. Taking that work means one of us eats the difference, and it usually ends with both parties unhappy and a client in the middle. Saying no early is cheaper for everyone, including us, even though it does not look that way on a sales report.

Where to start

Take last month. Split every hour your delivery people worked into four buckets: planned project work, unplanned support, waiting on someone, and rework. Do it roughly — precision is not the point. Most practices find that the first bucket is far smaller than they assumed, and that tells you whether you have a people problem or a process one. Then, and only then, decide whether to hire, subcontract or embed. If you want a second view on the answer, how buyers choose Odoo partners is a useful mirror: the things clients check are mostly the things capacity decides.