The Modular ERP Buyer's Guide for Growing Businesses

This is a longer, reference version of the questions covered in what to look for in an ERP for growing businesses — meant to be worked through directly during an evaluation, not just read once.

Who this guide is for

Businesses that have outgrown spreadsheets and disconnected point tools, but aren't large enough to justify a multi-year enterprise ERP rollout. Typically: 20 to a few hundred employees, running projects, purchasing, inventory and invoicing as core operational activity, where manual reconciliation between systems has become a measurable time cost.

If you're evaluating enterprise-tier systems (SAP, Oracle, Dynamics at the high end) with a dedicated implementation budget and team, most of this guide still applies conceptually, but the specifics of rollout timeline and cost structure will look different.

Part 1: Architecture

1.1 Is the data model genuinely shared, or nominally modular?

The single most important architectural question. A system with real shared architecture has one customer record, one project record, one item record, referenced by every module that needs them. A system that's modular only in licensing has separate applications sharing a login screen, each with its own copy of core entities.

How to test it: Ask the vendor to walk through one specific record — a customer, say — and show every place it's referenced: CRM, sales, projects, invoicing, logistics. If updating the customer's address in one place doesn't automatically reflect everywhere else, the data isn't actually shared.

1.2 What happens when you enable a new module later?

In a real modular architecture, enabling a new module means it starts reading data that already exists — no migration, no re-entry. Ask directly: if you enable Logistics a year from now, does it need your customer and project data re-entered, or does it read what's already in the system?

1.3 How is cost tracked against operational events?

For any business running projects, the critical architectural question is whether cost is a byproduct of operational events (material issued, hours logged, invoice raised) or a separate manual entry reconciled later. The former gives you live project profitability; the latter gives you a report assembled after the fact. See why project profitability requires connected data for why this distinction matters more than almost anything else on a feature list.

Part 2: Rollout and adoption

2.1 Realistic timeline

A modular system built around a shared core should let you get a core workflow — sales through invoicing — running with real data in weeks, not months. If a vendor's honest answer involves a multi-month implementation project before you see any value, understand that cost explicitly before committing, and weigh it against what you're actually trying to solve.

2.2 Incremental adoption

You shouldn't need to configure and roll out every module on day one. A sensible path: start with the core (customers, sales, procurement, inventory, finance), get it running against real operational data, then layer on field-specific modules (fleet, logistics) once the core is stable. If a vendor pushes you toward a "big bang" rollout of everything at once, ask why — it's often a sign the modules aren't independently useful, which circles back to the architecture question in Part 1.

2.3 Training and change management

The best-architected system still fails if the people using it daily can't get comfortable with it quickly. Ask to see the actual interface a warehouse clerk or a salesperson would use day-to-day — not just the executive dashboard. Complexity that's invisible to a manager is very visible to the person entering a goods receipt fifteen times a day.

Part 3: Cost structure

3.1 What's actually included

"Modular pricing" should mean you pay for the modules you use — not that core functionality within an enabled module is further gated behind add-on fees. Ask explicitly: within a module I'm paying for, is there additional functionality gated behind a higher tier? If so, get the full list before committing, not after.

3.2 Cost of connecting to what you already have

If you're not replacing every existing tool on day one, ask how the ERP handles the transition period — can it run alongside your existing accounting system temporarily, or does adoption require a hard cutover? Hard cutovers are riskier but usually cheaper; parallel running is safer but adds real cost during the transition.

3.3 What happens if you need to leave

A less comfortable but important question: how do you get your data out if you switch systems later? A vendor confident in their product should have a straightforward answer — data export in a usable format, not a vague "talk to support."

Part 4: Compliance and localization

4.1 Is your jurisdiction's tax model core or bolted on

For Saudi Arabia specifically, see the companion guide, ZATCA e-invoicing compliance for Saudi businesses. The general principle applies everywhere: if your regulatory invoicing requirements are core to daily operations, they need to be designed into the finance data model from the start — not added as a regional variant of a generic international invoice.

4.2 What's labelled honestly as not-yet-live

Any vendor demonstrating invoicing or compliance functionality should be explicit about whether what you're seeing is connected to a live regulatory platform or running in a demo/sandbox mode. If that distinction is blurred in a demo, it's a red flag for how the vendor treats compliance claims generally.

Part 5: Honesty about roadmap

5.1 What's built vs. planned

Every ERP has a roadmap. The vendors worth trusting are specific about the difference between what's shipping today and what's planned — a clearly labelled "Available / Expanding / Coming soon" status, ideally visible on their own product pages, not just told to you verbally in a sales call.

5.2 How they talk about gaps

Ask directly: "what's the biggest thing your product doesn't do well yet?" A vendor with a mature, honest product will have a specific, non-defensive answer. A vendor without one is either not being straight with you, or hasn't thought critically enough about their own product to know.

A condensed scorecard

Use this during a live demo — score each 1–3 based on what you actually see, not what you're told:

A system scoring low on shared data architecture will underperform on almost everything else eventually, regardless of how good it looks in a scripted demo — that's the one category worth weighting most heavily.