The most useful question a business can ask before commissioning any build. Here is the honest answer, including the cases where the answer is: you can, and you should.
Every serious systems conversation in Nairobi eventually arrives at the same question. A CEO has decided the spreadsheets, the WhatsApp approvals, and the five disconnected tools have become the ceiling on growth. Someone on the team has done the research. And then the question lands: why can't we just use Odoo? Or Zoho, or SAP Business One, or whichever platform the local implementer is certified in.
It is the right question. It deserves a better answer than the one most vendors give.
The implementer's answer is: you can, sign here. The custom developer's answer is: you can't, sign here. Both answers are sales pitches wearing the costume of advice. The honest answer depends on one thing neither party usually examines before quoting: whether your operations fit inside the platform's assumptions.
Platforms are opinions about how businesses work
An ERP is not a neutral container. It is a set of opinions, encoded in software, about how a business should run. Odoo has an opinion about what an invoice is, when it is issued, and what states it can pass through. Zoho has an opinion about what a customer record contains and how a sales pipeline moves. These opinions were formed across hundreds of thousands of businesses, which is precisely why they work so well for standard operations and so poorly for non-standard ones.
If your business matches the platform's opinion, implementation is fast, cheap, and low risk. A distribution company with conventional purchasing, inventory, and invoicing should not commission a bespoke build. Paying a studio to recreate what Odoo does well is paying a premium to reinvent a wheel that already rolls. We tell prospects this in the first meeting, because a build that should have been a configuration is a failure regardless of how well it is engineered.
The problem starts where your operating logic and the platform's opinion diverge. Every divergence becomes a workaround: a custom field carrying meaning the system does not understand, a manual step bridging two modules that were never designed to talk, an export to Excel where the platform's reporting ends and your actual question begins. One workaround is a nuisance. Thirty workarounds are a shadow system, undocumented, dependent on the two people who remember why each one exists, and invisible to any auditor, partner, or investor who examines the platform and assumes it reflects reality.
This is the platform ceiling. It is rarely visible at purchase. It becomes visible at scale, at audit, at integration, or at the moment a regulator or enterprise partner asks a question the workarounds cannot answer.
Where the ceiling tends to sit
Across the operations we have examined, the ceiling shows up in four recurring situations.
Genuinely non-standard operations. The business does something structurally unusual: a lending product with approval logic no module anticipates, a logistics operation where the unit of work is not an order but a route, a school where fees, scholarships, and payment plans interact in ways a standard billing module cannot express. Platform customisation can stretch a long way, but stretched customisation breaks at scale, and it breaks quietly. This is not a critic's claim. Odoo's own upgrade documentation states that a database containing custom modules cannot be upgraded until compatible versions of those modules exist, and that every new version introduces changes that can impact those customisations, with the rework falling on whoever maintains the custom code. The more you bend the platform, the more you pay at every version, forever.
Regulated environments. Compliance modules encode yesterday's rules. If you operate under CBK oversight, health data regulation, or licensing regimes that move faster than a platform's release cycle, your compliance posture is hostage to a vendor roadmap you do not control. Kenya's own regulators demonstrate the pace: KRA's eTIMS regime went from mandate to automated cross-checking of every declared income and expense within two years, with rules still being amended mid-filing-season in June 2026. Compliance designed into the architecture from inception is structurally different from compliance installed as a module.
Heavy external integration. M-Pesa, KRA, bank rails, partner APIs. Platforms integrate, but on their terms and within their API frameworks. Zoho's developer documentation, for example, sets daily credit budgets and caps the most resource-intensive API calls at ten concurrent requests on every plan. Limits like these are invisible in a demo and decisive in production. When your business is the hub of a web of integrations rather than a spoke, the platform's integration ceiling becomes your operational ceiling.
Customer-facing product. ERPs run internal operations. If what you need is a product your customers touch, a platform is the wrong category of tool entirely, and no amount of configuration changes that.
None of these automatically means bespoke. Each means the buy-or-build question cannot be answered from a features list. It can only be answered by examining how the organisation actually operates, which is why we will not quote a build before running a diagnostic. Sometimes the diagnostic concludes that Odoo, properly configured, is the answer. That conclusion costs a client far less than discovering the ceiling two years and several million shillings later.
The real cost comparison
The standard comparison is licence-plus-implementation versus build cost, and on that comparison the platform wins almost every time. It is also the wrong comparison, because it prices the purchase and ignores the ownership.
The fuller ledger includes the workarounds and the staff hours that operate them. The manual reconciliation between modules. The reporting you rebuild in spreadsheets because the platform's reports answer the platform's questions, not yours. The integration you cannot do, and the partnership it cost you. The migration you will eventually undertake anyway, now with five years of data shaped by someone else's schema. And the strategic cost that never appears on an invoice: an operating model slowly bent to fit the software, instead of software built to fit the operating model.
A business whose operations fit the platform pays none of these costs. A business whose operations do not fit pays all of them, on a delayed schedule, which is why the platform looks cheap in year one and expensive in year four.
The test
Strip everything above down to a single working test:
If your operations fit the platform's assumptions, buy the platform. If your operations are the advantage the platform cannot express, build.
Most businesses cannot answer which side of that line they are on from the inside, because the workarounds have become invisible through familiarity. That is the case for diagnosis before any commitment, to a platform or to a build. The most expensive systems decision is not choosing the wrong vendor. It is choosing before understanding what your organisation actually does.
Code Quarium is a Digital Systems Studio. Every engagement begins with an operational diagnostic. Sometimes the diagnostic recommends a platform. When it recommends a build, we build it. codequarium.tech
