There's an uncomfortable gap in the ERP market for growing businesses. On one end, enterprise systems like SAP or Dynamics are built for organizations with dedicated implementation teams and multi-year budgets. On the other end, lightweight tools solve one problem well but leave you stitching five of them together. If you're a business that's outgrown spreadsheets but isn't a 500-person enterprise, most of what's marketed to you doesn't actually fit.
Here's a practical way to evaluate what's in front of you, based on the questions that actually predict whether a system will still be working for you in two years.
Start with data architecture, not feature lists
Every ERP vendor's feature list will look similar — CRM, sales, procurement, inventory, finance. The feature list tells you almost nothing about whether those modules are actually connected or just menu items sitting next to each other.
The test: pick one workflow — a sale that leads to a purchase that leads to an invoice — and ask the vendor to show you, specifically, how data moves between those three steps without manual re-entry. If they can only describe it in the abstract ("everything's connected!") rather than show you the actual screens, that's a signal.
See ERP vs. disconnected business software for what this actually costs you when it's missing.
Check whether "modular" is real
As covered in how modular ERP systems work, "modular" can mean a genuine shared architecture, or it can mean a monolithic system with a licensing toggle. Ask directly: if I enable a new module in a year, does my existing customer and project data need to be migrated or re-entered into it, or does the new module just read what's already there? The answer tells you which kind of modular you're actually buying.
Evaluate implementation time honestly
A system that takes a year to implement isn't necessarily bad software — but it's a specific kind of commitment that most growing businesses can't actually afford, in time or money. Ask for a realistic timeline to get your core workflow — sales through to invoicing — running with real data, not a demo environment. Weeks is a reasonable expectation for a well-built modular system; if the honest answer is months, factor that cost in explicitly.
Look for honesty about what isn't built yet
Every serious ERP vendor has a roadmap — features that are planned but not yet shipped. The ones worth trusting are specific and separate about it: this is available today, this is in progress, this is planned. Vague language ("robust HR capabilities," "advanced manufacturing support") without a clear statement of current status is worth pushing on directly. If a vendor can't clearly tell you what's not built yet, assume the feature list is aspirational rather than descriptive.
Ask about your specific compliance requirements
If you're operating in Saudi Arabia, Saudi VAT and ZATCA e-invoicing support needs to be a first-class part of the finance module, not a generic international invoice with a few extra fields. See Saudi e-invoicing and ZATCA: what businesses need to know for what to actually check.
Whatever your jurisdiction, the same principle applies: compliance requirements that are core to how you invoice need to be designed into the data model, not added as an afterthought.
A practical checklist
| Question | What a good answer looks like |
|---|---|
| Does data move between modules without manual re-entry? | A live demo of one real workflow, not a slide |
| Is "modular" a real shared data architecture? | New modules read existing data, no migration |
| What's the realistic time to get running? | Weeks for core workflows, stated plainly |
| What's planned but not yet built? | A specific, labelled list — not vague future promises |
| Does it handle your specific tax/compliance needs? | Built into the core data model, not bolted on |
| Who actually owns your data? | Clear answer, in writing, before you sign anything |
The bar to hold vendors to
The single most useful discipline when evaluating ERP software for a growing business: don't let any vendor answer a specific question with a general claim. "Everything's connected" isn't an answer to "show me what happens when I issue material against a project." "We support Saudi compliance" isn't an answer to "which ZATCA invoice types does your data model distinguish."
Specificity is cheap for a vendor whose product actually works the way they say it does, and expensive for one that doesn't. Ask specific questions, and treat vague answers as the useful information they are.