Maybe Your Next ERP Feature Should Start as an MVP

The Problem with Big ERP Projects

Every ERP consultant has seen it. A company decides they need a new module — an e-commerce storefront, a customer portal, a warehouse management add-on. The project kicks off. Designers and developers disappear into a conference room for months, sustained largely by pizza and optimism. A requirements document the size of a small novel gets produced. A budget gets approved. And eighteen months later, a system gets delivered that nobody quite recognizes as the thing they originally wanted.

Features nobody asked for. Workflows built around assumptions. And somewhere buried in 400 line items of scope, the two or three things users actually needed every day.

There is a better way. It comes from the startup world, and it applies directly to ERP development.

What Is a Minimum Viable Product?

The term Minimum Viable Product — MVP — was popularized by Eric Ries in his 2011 book The Lean Startup, though the concept has roots that run deeper.

Ries drew heavily from Steve Blank, his mentor and the architect of Customer Development methodology. Blank's central argument was deceptively simple: before you build anything, get out of the building and talk to real customers. Test your assumptions against reality before committing resources. The product should be shaped by what customers actually need, not by what you think they need from behind a desk.

Ries also borrowed from Toyota's Lean Manufacturing philosophy — the discipline of eliminating waste, building in small iterations, and embedding feedback loops directly into the production process. In manufacturing, you don't produce 100,000 units before discovering a defect in unit one. You catch it early, correct it cheaply, and move on.

And the software world contributed Agile development — the rejection of long "waterfall" planning cycles in favor of short sprints, working software over comprehensive documentation, and responding to change over following a fixed plan.

The MVP synthesizes all three: build the smallest thing that works, put it in front of real users, learn from their behavior, and iterate. The goal is not to deliver a finished product — it is to answer a question as cheaply and quickly as possible.

Applying MVP Philosophy to ERP

Here is the insight that most ERP projects miss: MVP thinking applies just as powerfully to feature additions, standalone modules, and integration decisions as it does to startup products.

Before committing to:

• A full ERP module addition
• A platform-wide switchover to a new system
• A third-party software acquisition and integration

…you can — and should — build a small, intentionally limited version first. Not a prototype that gets thrown away, but a real working system that actual users interact with in real workflows. Its job is to surface the features that matter, expose the integration requirements you didn't anticipate, and generate a genuine Requirements Spec based on observed behavior rather than speculative design.

The hoped-for system should drive development. Actual, requested, observed needs — not a wish list assembled in a dark room.

A Concrete Example: The ERP Web Storefront

Let's say your company runs an established ERP — Sage 300, Sage Pro, or similar — and leadership has decided it's time to add an e-commerce storefront. The "eventual" vision involves deep integration: real-time inventory sync, customer account access, order history, automated invoicing, maybe a customer portal with service tickets.

The temptation is to spec all of that, issue an Requirements Spec for the full system, and build it. The result is a massive project with a massive price tag and a massive opportunity to get it wrong.

The MVP approach looks different.

Build a small, standalone web storefront first. Keep the integration intentionally loose — perhaps a nightly inventory export to a flat file that the storefront reads, and a manual or semi-automated order import back into the ERP. Nothing elegant. Nothing that would survive a true enterprise audit. But something real, that real customers use.

What you will learn from this MVP:

• Which product categories customers actually browse and purchase online vs. calling in
• What inventory data they need to see (just "in stock / out of stock"? Exact quantities? Lead times?)
• How they want to pay — net terms tied to their ERP account, or card on file, or something else?
• Where the integration breaks — what data the ERP produces that the storefront doesn't need, and what the storefront generates that the ERP can't easily absorb
• What the support burden looks like — what questions do customers ask that the system doesn't answer?
• Which features from your original spec nobody touches

After six months of real usage, you have something invaluable: an Requirements Spec grounded in evidence. You know which integrations are worth the engineering cost. You know which features are genuinely needed versus theoretically desirable. You know where the pain points are. And you can issue a scope document for the "real" system that reflects what the business actually does, not what a design session imagined it might do.

The loosely-integrated MVP is not a failure state. It is the research phase.

The "Dark Cave" Anti-Pattern

The alternative — what we might call the Dark Cave approach — is to seal your team into a damp cave populated by fast food fed developers and expect them to produce a comprehensive requirements document from first principles.

This process generates features in abundance. It rarely generates the right ones.

The problem is not that designers are incompetent. It is that nobody knows what users actually need until users interact with an actual system. Requirements gathered through interviews and workshops reflect what people say they will do. Behavior in a live MVP reflects what they actually do. These are reliably different.

Lean Manufacturing understood this. You do not design a production line in isolation and then hand it to workers — you watch how work actually flows and design around reality. Agile understood this too: ship something working, get feedback, adjust. The ERP world has been slow to apply the same logic to its own project methodology.

When to Apply MVP Thinking in ERP Contexts

This approach is applicable wherever there is meaningful uncertainty about requirements — which is to say, nearly every major ERP decision:

• New customer-facing modules (storefronts, portals, mobile apps) where user behavior is hard to predict
• Third-party software integrations where the real data exchange requirements only become clear under load
• ERP platform migrations where a pilot on a subset of business units surfaces integration gaps before a full rollout
• Warehouse or logistics add-ons where floor-level workflow requirements diverge from what management describes

The common thread: any time a large, expensive commitment is being made on the basis of assumed requirements, a small, real, working version can test those assumptions cheaply first.

When NOT to Use the MVP Approach

The MVP framework is powerful, but it is not a universal answer. There are situations where it adds overhead without adding value — and a few where it can actually make things worse.

1. The feature is too small to warrant it. If you are adding one or two discrete functionality points — a new report, a lookup field, a tax code — there is nothing to learn from a stripped-down version. The scope is already minimal. Build it, test it, ship it. Wrapping a two-hour development task in a six-week MVP process is process for its own sake.

2. You have no idea how to build it at all. This one is a red flag that often gets overlooked. An MVP assumes you understand the technical approach well enough to build a limited version of it. If the core engineering is genuinely unknown — if no one on your team or vendor roster has done anything close to this before — then you do not have an MVP problem, you have a discovery problem. Spend the time on technical proof-of-concept and vendor evaluation first. An MVP built on a shaky technical foundation does not validate requirements; it validates the wrong foundation.

3. There is no room for the learning loop — extreme urgency applies. Sometimes the business reality is that the full system needs to be live on a fixed date and there is no time to iterate. Signing Walmart as a customer and discovering they require EDI compliance before the first purchase order is a real scenario — and it is not one where you have the luxury of a small, loosely-integrated test. When a contract or regulatory deadline dictates the scope and timeline, MVP thinking gives way to disciplined execution: define the requirements as tightly as possible, staff it correctly, and build it right the first time.

4. The integration is so tightly coupled that a loose version is meaningless. Some ERP workflows have so many interdependencies — payroll tax compliance, multi-entity consolidation, government reporting — that a partial implementation does not behave like the full one. Testing a thin slice tells you nothing useful about how the real system will perform. In these cases, a well-scoped pilot on a contained data set is more appropriate than an MVP.

The bottom line: Consider the MVP approach first. Ask whether there is meaningful uncertainty about what needs to be built, and whether a working small version can answer that question before you commit to the full scope. In most cases involving new modules, customer-facing features, and third-party integrations, it can. But it is a tool, not a doctrine — and the right tool depends on what you are actually trying to learn.

Practical Takeaways

1. Define the question before you define the system. What specific assumption are you testing? For a storefront MVP: "Do our customers want to order online, and if so, what do they need to do it?"

2. Build loose integration intentionally. Tight integration is expensive and locks in design decisions early. A flat-file export or a manual sync is not a bug — it is a feature of the MVP phase. You will learn what the integration needs to do before you build it properly.

3. Measure behavior, not satisfaction. Users will say they love features they never use. Watch what they actually click, where they abandon, what they call in to ask about.

4. Set a time box and a decision point. The MVP phase should have a defined end: a date at which you review what you've learned and either iterate, expand, or write the real Requirements Spec.

5. The MVP output is the Requirements Spec. Everything you observed — the unexpected integration requirements, the missing features, the features nobody used — becomes the evidence base for the actual project scope.

Conclusion

The MVP philosophy did not emerge from software startups alone. It emerged from a recognition that assumptions are expensive and evidence is cheap. Eric Ries synthesized it. Steve Blank planted the seed. Toyota proved the principle on the factory floor decades before the first line of business software was written.

ERP projects are not exempt from this logic. A small, intentionally limited, loosely-integrated system — built to learn rather than to last — is not a compromise. It is the most rigorous path to building the right system in the end.

Before you approve that Requirements Spec, build something small enough to tell you what the Requirements Spec should actually say.

Frequently Asked Questions

Q: Doesn't building two systems cost more than building one? Not if you think of the MVP as the research phase rather than a throwaway project. The cost of a small, loosely-integrated MVP is almost always a fraction of the cost of getting a full-scale Requirements Spec wrong. One failed ERP module — built around assumed requirements — routinely costs more than a dozen well-scoped MVPs.

Q: How loosely integrated does the MVP need to be? Loose enough that integration decisions haven't been locked in yet. A nightly flat-file export, a manual import step, even a spreadsheet handoff — these are fine. The point is to learn what data actually needs to flow between systems before you pay to build a proper interface. Premature tight integration is one of the most expensive mistakes in ERP projects.

Q: How long should the MVP phase run? Long enough to capture real usage patterns, short enough to remain actionable. For most ERP add-ons, 90 to 180 days gives you a meaningful dataset. Set a hard decision date at the outset: you are not running the MVP indefinitely, you are running it to answer a specific question by a specific date.

Q: What if users just keep using the MVP instead of demanding the full system? That is useful data too. It may mean the full system is over-engineered for the actual need, that the MVP covers more ground than expected, or that the integration requirements are lighter than anticipated. "Users are happy with the MVP" is a legitimate outcome that can save significant development cost.

Q: Does this apply to full ERP platform migrations, or just add-on modules? Both. For a full migration, the MVP approach might mean running a single business unit or a single workflow on the new platform while the rest of the organization stays on the existing system. You surface integration gaps, training needs, and workflow mismatches on a small scale before committing the whole organization.

Q: What makes this different from a pilot program? A traditional pilot tests whether a finished system works in a real environment. An MVP tests whether your assumptions about what the system needs to do are correct — before the system is fully built. The MVP shapes the Requirements Spec. A pilot validates it.

Q: Our ERP vendor says we need to commit to the full module to get started. Is that normal? It is common, but it is worth pushing back on. Many vendors offer phased implementations, starter tiers, or sandbox environments. If a vendor cannot support an incremental approach, that itself is important information about how the relationship will go when requirements change — and they always change.