ERP in 30 days on agreed scope: how the delivery model works
The 30-day claim is a delivery model, not a marketing promise. What realistically fits in 30 days, what does not, and why the agreed scope makes the difference.
“ERP in 30 days” sounds to many executives like a marketing number at first. In practice it is a delivery model claim with a specific condition attached: on agreed scope. Those three words decide whether the claim is credible or a promise that breaks down mid-project. Understanding what Nuclos Enterprise actually delivers in 30 days starts with understanding what “agreed scope” means and what is deliberately left out.
What 30 days means
30 days is the time from project start to productive go-live of a clearly defined core process. Nuclos Enterprise delivers your productive ERP on agreed scope, typically within 30 days, at a fixed price starting at 10,000 Euro plus VAT. The result is not a prototype or a demo. It is a system that users actually work in from day 30 onward.
The condition behind it: scope is fixed before implementation starts. That usually means a 48h prototype or a requirements specification already exists, or an existing requirements document describes the processes precisely enough. Without that groundwork, neither a credible fixed price nor a binding delivery date can be set. How scope clarification and fixed price relate to each other is covered in Fixed price and fixed scope in ERP.
What does NOT fit in 30 days
The 30-day claim applies to one well-defined core process, not to an ERP initiative of any size. Three categories of requirements deliberately do not fit this window and are planned as phase 2:
- Large rollouts across multiple departments or sites. Migrating purchasing, production, sales, and accounting to a new system all at once exceeds the scope of a 30-day project. It makes more sense to start with one core process and add further areas in clearly cut expansion stages.
- Extensive legacy data migration. Cleaning and transferring accumulated master data from legacy systems is a project in its own right, with its own timeline, not a side step within 30 days. Details in ERP data migration: avoiding pitfalls.
- Complex integration of multiple third-party systems. A handful of well-documented interfaces can be planned within scope. An integration landscape with many legacy systems and unclear data flows needs its own analysis and its own timeline.
This boundary is not a weakness of the model, it is its foundation. A vendor who promises 30 days for a multi-department rollout with an unresolved data situation is promising something they cannot keep. That kind of expectation gap is one of the most common causes of failed ERP implementations, see ERP implementation: avoiding common mistakes.
Why “agreed scope” is the decisive piece
Without the qualifier “on agreed scope,” the 30-day claim would be arbitrary and therefore not credible. With it, the claim becomes verifiable: before the project starts, it is documented in writing which processes, screens, workflows, and interfaces are part of the delivery, and which explicitly are not. This definition rarely happens at a desk. It typically comes from a preceding step:
- A 48h prototype makes one sub-process clickable and shows concretely what the core process covers, for a fixed price of 950 Euro plus VAT.
- A requirements specification documents processes, data model, and interfaces in a structured way when the starting situation is more complex.
- An existing, sufficiently precise requirements document can serve as the basis directly.
Which of these paths fits depends on the starting situation and is covered in the guide Which Nuclos entry path fits your situation?. Either way, the more precisely the scope is described before signing, the more reliable the 30-day commitment is. Additional needs that surface during the project are not informally pulled into the running build. They are evaluated as a change request or planned for phase 2.
How the four weeks unfold
The 30 days are not a single development sprint. They are four phases with a different character each:
| Week | Focus |
|---|---|
| Week 1 | Scope lock-in and setup: final alignment on agreed scope, environment setup, base data model |
| Weeks 2 and 3 | Build and configuration of workflows, screens, and process logic, with ongoing incremental testing by the customer team |
| Week 4 | Hardening, fixes from testing, user training, go-live |
The decisive detail in this structure is that the customer works with and tests the emerging system starting in week 2, not only at the end. Deviations from expected behavior surface while there is still time to correct them within the agreed scope, instead of being discovered at go-live. This cadence is also why an unresolved scope breaks the model: without a clear starting point in week 1, there is nothing concrete to test in week 2.
A delivery model, not a universal promise
30 days on agreed scope is a claim about the Nuclos Enterprise delivery model, not an unconditional promise for every ERP project of every size. For a well-cut core process with scope clarified in advance, the number is real and repeatedly achieved. For a company-wide rollout with an unresolved data situation and several third-party systems, the same number would not be credible. The difference between the two cases is not the software. It is whether someone invested the work of describing the scope precisely before the start. Whoever front-loads that work through a prototype or a specification buys the reliability of the 30-day commitment along with it.