Custom ERP Development in Kenya
CloudSpinx builds custom ERP software for businesses, SACCOs and institutions in Kenya and across East Africa, on Odoo, ERPNext and Frappe: custom modules, the workflow no standard system ships with, and the integrations that make it usable here. We build on an open-source core you own rather than from nothing, because an ERP written from scratch costs several times more to keep than to build. Development is quoted per engagement, and discovery tells you honestly how much of what you want is a configuration change you should not be paying a developer for.
Who we build for
- 14organizations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our Custom ERP Development Service
Every engagement covers the full scope: no hidden extras, no upselling.
Custom Odoo module development
Python modules that inherit the standard models instead of editing them, so your logic survives the next major version. The distinction between a module and a fork is the whole difference between an upgradeable system and a dead end.
Odoo customization
Views, reports, approval chains, automated actions and server-side rules built to match how the business actually runs. Most requests that arrive as development work land here, and cost a fraction of a module.
ERPNext and Frappe app development
Custom DocTypes, workflows and full applications on the Frappe Framework. MIT licensed underneath, GPLv3 at the ERPNext layer, and the difference matters if you ever plan to sell what we build.
Bespoke business systems
Where no ERP genuinely fits: fleet and logistics operations, out-grower and aggregation schemes, SACCO and member systems, school and institutional management. Built on a framework rather than from nothing.
ERP integrations
KRA eTIMS, M-Pesa paybill and till reconciliation, Airtel Money, bank statement feeds, payment gateways and whatever internal system already holds the data. Written with the failure cases handled, not just the happy path.
Legacy system replacement
The Access database one person understands, the spreadsheet estate, the custom PHP system whose author left in 2019. Modeled, migrated, reconciled and retired without a gap in operations.
Custom reporting and dashboards
The board pack, the regulator return, the daily operational view somebody currently rebuilds by hand every morning. Usually the fastest payback in a custom scope and the first thing we look for.
Module upgrade and porting
Taking someone else's custom module across a major version, which is the work that quietly blocks every stalled Odoo upgrade in the country. We quote it as its own engagement because it usually is one.
Code review and project rescue
A custom build that has stalled, run over, or arrived undocumented. We read the code, tell you what is salvageable and what is not, and say so plainly even when the answer is that you should stop.
Technologies we use
What we draw before anyone writes a line of it
Three figures that decide a custom ERP project before the code does: how much of the system you are actually paying to write, what the platform's license lets you do with the module afterwards, and the bill that arrives three years later. Module scope and effort come out of the specification phase.
Three ways to get a custom ERP, and how much of it you end up owning
Most buyers asking for custom ERP development want the middle column and are quoted the right-hand one. The accent blocks are the only parts anyone writes for you. Everything below the seam already exists, is maintained by someone else, and is free. Build from scratch and you have quietly bought the whole stack, including the plumbing nobody demos.
- written for you
- already exists, maintained by others
- yours to carry permanently
The core platform's license decides what you can do with the module you paid for
Nobody raises this before the contract and it is the question that matters if you ever plan to sell the thing. If the module only ever runs inside your own business, all three cores are equivalent and you can stop reading. If you intend to resell it to the next SACCO or the next school, the core you picked on day one has already decided the answer. This is how the licenses read, not legal advice: a lawyer signs off before you productize anything.
- no obligation on you
- permitted, with a condition
- the source goes with it
The bill a custom ERP module sends you three years after you paid for it
Odoo gives each major release three years of support and ships a new one every year, so staying supported means crossing a major version. Its upgrade service is explicit about what happens next: a database containing custom modules cannot be upgraded until a version of your custom modules is available for the target version. That port is not in the build quote you are comparing, and it recurs. Every module you agree to is a permanent line item, which is the real reason we argue you into fewer of them.
- supported, and what you paid for
- unsupported, and what nobody quoted you
Read across the three figures and the argument is one sentence: every block of accent color is a permanent commitment, so the cheapest custom ERP is the one where that block is as small as your business genuinely allows. Our first job on a build is arguing that block smaller, which is a strange thing to sell and the reason clients stay.
What custom ERP development costs in Kenya
Nobody can price this from a web form, and any figure you are given before somebody has looked at your processes is a guess dressed as a quote. What we can tell you is what actually moves the number, and where the money goes that buyers do not expect. The build is rarely the expensive part. The specification is where the risk sits, and the maintenance is where the money goes.
What moves the number
How many distinct processes need building rather than configuring, how deeply each touches accounting (anything that writes to the ledger costs more because it has to be right), how many integrations, the state of the data you are migrating, and whether you need the system to survive an upgrade unattended. One clean module against a standard core is a small piece of work. Four modules that interlock, write to the ledger and talk to two external systems is a different project, and pretending otherwise at quoting time is how builds run over.
The number the market quotes, and what it leaves out
Kenyan development shops do publish bands: one prominent local ERP page quotes basic systems from KES 150,000, mid-range from KES 200,000, and their top band from KES 700,000 upward. Treat those as build-only figures, because that is what they are. None of them price the port at the next major version, and on Odoo that arrives on a schedule you do not control. Compare quotes on five-year cost of ownership or you are comparing the cheap half of the number.
Why we quote a specification first
On anything beyond a single module we sell the specification as its own small piece of work, and you can take it to another developer. That sounds like a way to lose the build. It is actually the only honest way to price one, because a fixed price against a vague scope is either padded to cover the unknown or renegotiated halfway through, and you pay for the unknown either way.
Custom ERP, or the standard one configured properly?
This is the question we ask first and it is the one that saves clients the most money, so it is worth being blunt about the pattern. Most requirements that arrive described as custom development are a standard module configured differently, a report nobody built, or a process that could be changed more cheaply than it could be automated. Genuinely custom work exists, we do plenty of it, and it is a smaller fraction of what comes in than anybody expects.
- It is configuration if the data already fits the standard models and what you want is different fields, different views, a different approval path or a report. This is most of it, and it is days rather than weeks.
- It is a custom module if the business has an object the ERP has no concept of, or a calculation nobody else in your industry does the same way. An out-grower payment cycle, a member dividend rule, a fleet job costing model.
- It is a bespoke system only when the operation is genuinely not an ERP shape at all, and the ERP would be a shell around your real application. Rarer than the market implies, and when it is true it is obvious within an hour.
- It is a process problem more often than anyone wants to hear. If the requirement exists because two departments will not share a number, software will encode the argument rather than settle it.
The license decides who ends up owning your custom module
Almost nobody raises this before a contract is signed, and it is the detail that decides whether the module you paid for is an asset you can sell or a cost you can only use. The three cores we build on carry three different licenses and they are not interchangeable. Odoo Community is LGPLv3, which permits a separately licensed module alongside it, which is precisely why a market in paid closed-source Odoo apps exists. ERPNext is GPLv3, so a module that is a derivative work carries the same license when you distribute it. The Frappe Framework underneath ERPNext is MIT, which places no obligation on you at all.
When none of this matters
If the module only ever runs inside your own business, no copyleft obligation is triggered by any of the three, and you should pick a platform on fit and on who can maintain it. We say this rather than using the license as a reason to steer you, because for most clients it genuinely is not a factor and treating it as one would be a sales tactic.
When it decides the platform
If there is any chance you will sell the system to the next SACCO, the next school or the next distributor, the core you choose on day one has already answered the question. We ask about it in the first conversation for exactly that reason, and we put the answer in writing before development starts. This is how the licenses read rather than legal advice, and anybody planning to productize should have a lawyer confirm it.
Odoo, ERPNext or Frappe for a custom build
We build on all three and hold no reseller incentive in any direction, which is the only position from which this comparison is worth reading. The choice is usually decided by how much standard ERP you actually need underneath the custom part.
- Odoo when you need real ERP depth under the custom work: accounting, inventory, manufacturing and a large app ecosystem, with your module sitting on top. Best developer availability locally, and LGPLv3 keeps your module's licensing flexible.
- ERPNext when you want a complete ERP with no per-user cost and your customization is bounded. Strong fit for NGOs, member organizations and public bodies where an open license also helps procurement.
- Frappe Framework alone when the honest answer is that you are building an application, not extending an ERP. You get the data model, permissions, workflow engine, REST API and admin UI for free, and you skip the ERP you were never going to use.
- Not one of the three if the system is really a customer-facing product. That is a web and mobile build with its own stack, and forcing it onto an ERP framework to save time costs more within a year.
Where a standard ERP genuinely does not fit
These are the sectors where custom development is the right call rather than the expensive one, and they have a shape in common: a core operational process that is the business itself, priced or regulated in a way no global ERP models.
- SACCOs and member organizations. Share capital, member deposits, dividend and interest rebate calculations, guarantor chains and loan appraisal rules. SASRA reporting alone justifies custom work, because the return has to come out of the system rather than out of somebody's spreadsheet at quarter end.
- Fleet, transport and logistics. Trip costing, fuel and driver reconciliation, maintenance scheduling against mileage rather than dates. We have built an operational system at fleet scale and the write-up is on our case studies page.
- Agriculture and out-grower schemes. Collection by weight at multiple points, quality grading that changes the price after the fact, deductions for inputs advanced months earlier, and payment cycles no standard payables module expects.
- Schools and institutions. Fee structures with terms, transport zones, bursaries and arrears that behave nothing like an invoice, plus the reporting a board and a ministry both want in different shapes.
What Kenyan localization has to cover in custom code
A custom module that touches money in Kenya inherits every statutory rule the standard system was already handling, and this is the most common way a bespoke build goes quietly wrong. Write a custom payroll calculation and you now own PAYE bands, NSSF tiers, the Affordable Housing Levy and SHIF at 2.75% of gross with no upper cap. NHIF stopped existing when the Social Health Authority began operating, so any custom code, or any developer's documentation, still working in NHIF bands is producing wrong filings today. Write a custom invoice flow and you own eTIMS transmission including credit notes and what happens when KRA is unreachable mid-invoice. This is the strongest argument for building on a core someone else keeps current: the parts that change by statute should not be the parts you wrote. Where a full packaged implementation is the better answer, that runs through our ERP and CRM implementation work instead.
When we tell clients not to build custom
A good share of the businesses who ask us for custom ERP development should not buy it, and saying so costs us a build and wins the relationship.
- When the standard module does it and nobody checked. This is the most common outcome of a first call. We would rather spend an afternoon showing you the configuration than a month building around it.
- When nobody internally will own the requirement. Custom work needs one person on your side who can decide how a process should behave and make the decision stick. Without that the specification never closes and the cost runs.
- When the real driver is a report. Wanting a number nobody can currently produce is a reporting job, often a week of work. It arrives described as a new system surprisingly often.
- When you cannot carry the maintenance. Every module is a permanent commitment at every future upgrade. If the budget exists for the build and not for the years after it, the honest recommendation is to change the process and keep the system standard.
- When you are mid-restructure. Custom code written against an org chart that is about to change gets written twice. Wait, and spend the interval on the specification.
What you own at handover
The module source in a repository you control, the commit history, the technical documentation, the data model, the migration scripts and the test cases. All three platforms we build on are open source at the core, so there is no proprietary layer of ours in the middle of your system and no license held in our name. We also write down, before development starts, which major version the module was built against and what porting it will involve, because that is the cost nobody quotes and it is the one that decides whether you are still happy with this decision in three years. If you want us to carry the upgrades, that is a retainer; if you want your own developer to take it on, the documentation is written for them rather than for us. Ongoing platform hosting, if you need it, runs through our managed hosting.
Tell us what the standard system will not do
Enough for us to work out how much of this is genuinely custom. The questions about process and data decide the price; the one about reselling decides the platform.
Ready to discuss Custom ERP Development?
A 30-minute scoping call, free, and it commits you to nothing.
How Every Custom ERP Development Engagement Starts
Discovery and honest triage
What the process actually does today, including the workarounds. Then the split: what is configuration, what is a report, what genuinely needs writing. You get that answer even if it means there is no build in it for us.
Specification and platform choice
A written functional specification, the data model, the integration contracts, and the platform decision with the licensing consequence stated. Priced as its own piece of work, and yours to take anywhere.
Build, integrate and test
Modules written against the standard models rather than editing them, in a repository you own from the first commit. Integrations tested against real transaction volume, not three sample payments.
Handover and the port plan
Documentation, source, test cases and training. Plus the written note of which major version this was built against and what the next upgrade will need, so the cost is on the table years before it lands.