Every ERP demo you'll ever sit through is the best that software will ever look. It's been rehearsed, the data is clean, the workflow is the happy path, and every click lands exactly where it's supposed to. That's not a criticism, it's just what a demo is for. The problem is when businesses use that hour as their main basis for comparing platforms, because the real evaluation question isn't “does this look good?” It's “does what I'm being shown reflect what I'll actually have on day one of go-live?”
That gap, between demo and delivery, is one of the more reliable signals of implementation risk. It applies whether you're weighing up NetSuite, Odoo, or anything else, and it's worth understanding before you get deep into a vendor process rather than after.
Why the Gap Exists
Most often, a demo is built to show a platform's capability, not your specific configuration. Sales engineers configure a clean environment with the vendor's best-case data and workflow, tailored to look effortless. That's fine as a first look, but it's not the only way to run one. At Project Salsa, we build demos around your actual configuration where we can, so you're seeing how the platform will work for your business, not just a generic walkthrough. Where a demo becomes a problem is if a business mistakes "this platform can do that" for "this is what we'll have," which is exactly the gap a configuration-specific demo is meant to close.
Where This Shows Up Differently Across Platforms
Part of that gap comes down to how much of a platform is native, and how much has to be built. NetSuite runs on a single, unified instance where most functionality is configured rather than custom-coded. Odoo is open-source, and its flexibility comes from customising the underlying code directly. Neither model is right or wrong on its own, but it does mean the two platforms carry different amounts of this risk by design.
The more a solution relies on custom modules or third-party extensions to do what you saw in the demo, the more your business owns that code, and the more attention it needs every time the platform moves.
Customisation isn't the enemy here. Building your way to functionality you assumed was standard is a different thing entirely, and it's a cost that doesn't go away once the project's signed off.
Neither native functionality nor customisation makes a platform universally right or wrong. It just changes what questions are worth asking, and when.
Questions Worth Asking Before You Sign
A few questions tend to surface the gap early, regardless of which platform you're evaluating:
-
Was what I just saw configuration, or was it built specifically for this demo?If a feature required custom development to show you, ask how long that took and who owns maintaining it going forward.
-
What does the environment look like on day one, versus month six?Some functionality is deliberately staged in phases. That's often sensible, but it should be an explicit part of the plan, not something discovered mid-project.
-
Who is responsible for keeping customisations working through future updates?This matters most on open-source platforms, where custom code has to be reworked at each new release to stay compatible. Ask what that process looks like and who carries that cost.
-
Can I see a reference implementation that's been live for at least a year, not just gone live?A fresh go-live tells you the project team can build to spec. A business running the system a year in tells you whether it holds up once the honeymoon period ends.
-
What's the actual timeline from contract signature to go-live, based on the last three projects of similar scope?Not the vendor's best-case estimate, the real range.
The Point Isn't to Distrust the Demo
None of this is an argument against demos, or against either platform. It's an argument for treating a demo as the start of due diligence rather than the end of it. The businesses that get the best outcomes, on any ERP, are the ones that go in with a clear picture of their own complexity and ask pointed questions about how that complexity gets handled between the demo room and go-live.
If you're partway through evaluating NetSuite against Odoo and want a clearer read on how this plays out for your specific requirements, our full NetSuite vs Odoo comparison covers the functional, pricing, and implementation differences in more depth. And if you'd rather talk it through directly, we're happy to have an honest, no-obligation conversation about where your business sits.
Not Sure Where to Start?
If you're putting together a shortlist and want an honest read on which ERPs are actually worth demoing for your business, we're happy to help. Get in touch and we'll talk through your requirements, no pressure, no sales script, just a straightforward conversation about what fits.
FAQs
How long should an ERP demo be before I can trust it?
Length isn't really the signal, specificity is. A generic hour-long walkthrough of standard features tells you less than a shorter session built around your actual data and process. If a vendor can't or won't demo against something close to your real scenario, that's worth noting.
Is it normal for a vendor to build something specific just to show me in a demo?
Yes, and it's not a red flag on its own. It becomes one if the vendor doesn't clearly separate "this is native functionality" from "this is something we built to answer your question." Ask directly which parts of what you saw exist today versus what would need to be built.
What's a reasonable number of reference customers to ask for?
Two or three is usually enough, provided at least one has been live for a year or more. A reference that went live last month can confirm the implementation team delivered to spec, but it can't tell you how the system holds up once real-world usage and the first upgrade cycle kick in.
Should I get the implementation timeline in writing before signing?
Yes, and ideally tied to scope, not just a date. A timeline without an agreed scope attached tends to be the first thing that slips when requirements shift during the build.
Who should be in the room for a vendor demo?
Whoever will actually use the system day to day, not just the decision-maker. Operational staff are more likely to spot the gap between "this looks good" and "this fits how we actually work," and their questions often surface scope issues earlier than a leadership-only session would.
Does this apply if I'm only evaluating one platform, not comparing two?
Yes, arguably more so. Comparison naturally invites scrutiny; a single-vendor process can drift into taking claims at face value simply because there's nothing to benchmark against. The same questions are worth asking regardless of how many platforms are on your shortlist.
