Every growing company reaches the same question: should we buy an ERP system or build software around how we actually work? The honest answer is that it depends on how unusual your processes are, how fast they change and what you are willing to own. This guide gives you a way to decide without relying on a vendor's pitch.
What an ERP is good at
An enterprise resource planning system gives you finance, procurement, inventory, sales and HR on one shared data model. Its strength is that these functions are already connected and have been refined across thousands of customers. General ledger, invoicing, stock movements and payroll inputs behave the way an accountant or auditor expects.
If your processes are mostly standard, a packaged ERP is usually the right starting point. You get years of accumulated domain knowledge, a vendor roadmap and a pool of consultants who already know the product. You also avoid reinventing solved problems such as double-entry bookkeeping or tax handling.
Where packaged ERPs struggle
Trouble starts when your business does something the product does not expect. Common examples are unusual approval chains, industry-specific contracts, deployment of workers across client sites, or pricing rules that depend on several variables at once. Teams then pay for customisation, and each customisation makes upgrades harder.
The second struggle is breadth. A large ERP exposes hundreds of screens, and staff who need three of them still have to learn the navigation of all. Adoption suffers, and people go back to spreadsheets for the work the system makes awkward.
- Customisation debt: every change to the core makes future upgrades slower and riskier.
- Licence growth: per-user pricing rises as more departments come on board.
- Process drift: staff change how they work to fit the tool, not the other way round.
What custom software is good at
Custom software is built around your workflow. A staffing company can model contracts, deployments, rosters and billed versus unbilled revenue the way its managers think about them. A marina operator can combine memberships, berth billing and ledgers in one place. There is no unused functionality to learn and no licence tied to headcount.
You also control the roadmap. When a regulation changes or a new payment provider is needed, you schedule the work yourself instead of waiting for a vendor release.
What custom software costs you
You take on ownership. Someone has to maintain the code, upgrade frameworks, patch security issues and keep documentation current. Without that discipline, custom systems age badly. You also bear the risk of building something that already exists in a mature product, which is wasteful when the process is not truly unique.
The best protection is to treat custom software as a product: tests, continuous delivery, a backlog and a named owner. If you cannot commit to that, buy a package.
A decision framework you can apply this week
List your ten most important processes and score each on two questions. First, does this process differentiate us from competitors or is it table stakes? Second, does a mainstream product handle it with only configuration? Table-stakes processes that a product handles by configuration belong in a package. Differentiating processes, or those no product handles, belong in custom code.
- Commodity and well served: general ledger, payroll, basic inventory. Buy.
- Commodity but poorly served in your market: local tax or government integrations. Buy and extend through an API, or build a thin integration layer.
- Differentiating: your pricing logic, deployment planning, client portals. Build.
The hybrid approach most companies end up with
In practice, the strongest setups use a packaged core for finance and standard operations, with custom modules and portals around it. The custom pieces talk to the core through APIs and a message queue so the core stays upgradeable. Our ERP development and API integration work often takes exactly this shape, for example the two-way synchronisation platform described in our Tahweel case study.
Whichever route you choose, insist on three things: a documented API, an export of all your data in an open format, and a clear owner for every integration. Those three protect you from lock-in whether the vendor is a software company or an agency.
Questions to ask before you sign anything
- What happens to our customisations at the next major upgrade, and who pays for the rework?
- How is pricing calculated when we double our users or add a subsidiary?
- Can we get a full data export, including history and attachments, at any time?
- Who maintains integrations when a third-party API changes?
- What is the realistic timeline to the first department going live, not to the entire rollout?
How long each route takes to deliver value
A configured package can put finance and inventory live within months when the business is simple. Custom builds should release in slices: choose the module that hurts most, ship it in weeks, and expand. The danger on both sides is the big-bang go-live that touches every department at once. Whatever you choose, phase the rollout and measure adoption after each phase.
A worked example: a staffing company
Consider a staffing business that places workers on client sites. Its finance needs are ordinary: invoicing, payables, a general ledger and VAT. Its operations are not. Contracts specify rates by role and shift, workers are deployed and redeployed, attendance is captured from several sources, and revenue must be reported as billed and unbilled. A packaged ERP handles the finance well, and struggles with the deployment and attendance logic.
The sensible design is a custom workforce module that owns contracts, rosters and attendance, feeding approved totals into the packaged finance system through an API. Finance keeps its proven ledger, operations get software shaped like their work, and the boundary between them is a small, well-tested set of messages. The same pattern applies in healthcare clinics, fleet operators and marinas.
Total cost of ownership over five years
Compare options on a five-year view, not on the first invoice. For a package, add licences that scale with users, implementation partner time, customisation, hosting or subscription fees and annual support. For custom software, add the build, hosting, a maintenance allowance and enhancements. Include the cost of internal staff time in both cases, since training and process change are rarely free.
Two effects regularly change the answer. Per-seat licences make packages expensive when many occasional users need access, such as field staff or approvers. And heavy customisation makes packages more expensive to upgrade, which erodes the speed advantage they had at the start. Put numbers on both before deciding.
Risks on each side and how to reduce them
- Package risk: lock-in. Mitigate with API access, full data export rights and a contract that covers price increases.
- Package risk: poor fit. Mitigate with a paid proof of concept on your three hardest processes before committing.
- Custom risk: key-person dependence. Mitigate with documentation, tests and code that more than one person understands.
- Custom risk: scope drift. Mitigate with phased releases and a product owner empowered to say no.
Bottom line
Buy what is standard, build what is distinctive, and integrate carefully between them. If you want an independent view on your own processes, our IT consulting team can run a short assessment and give you a written recommendation with the assumptions behind it, so you can compare the options on your own terms.