The right order to launch an ERP: standard, low-code, then custom

Launching an ERP in phases gets a working system live early and keeps the cost and risk of the project under control. The approach is simple to state: go live on standard configuration first, add low-code changes second, and build custom code last, only for what nothing else can cover.

A phased ERP launch is an implementation approach that goes live on standard configuration first, then adds low-code customization, and finally builds custom code only for the requirements nothing else can meet. This piece sets out the three phases, the order to run them in, and why the order is what protects your budget and your timeline. The approach fits most operations, though it depends on the business being ready to settle its core decisions early.

What is a phased ERP launch?

A phased ERP launch goes live on standard configuration first, then layers low-code changes, and reserves custom code for last. Each phase carries more cost and complexity than the one before, so the sequence moves from the fastest and safest work to the slowest and most expensive.

The three phases map directly to the three levels of ERP customization, and cost and complexity rise at each step while upgrade safety falls. 

• Phase one is standard, out-of-the-box configuration, applied to your processes; it is the fastest and cheapest level, it is upgrade-safe, and it ships first in every project. 

• Phase two adds low-code changes through the platform's built-in configuration tools, such as extra fields, views, and simple automation, at low cost and with little upgrade risk, and it ships when configuration alone cannot meet a requirement. 

• Phase three is custom code, hosted in the cloud or on-premise; it is the slowest and most expensive level and it requires upgrade testing, so it ships only for requirements that are unique to the business and impossible at the first two phases.

Phase 1: launch on standard configuration

Phase one puts the business on out-of-the-box ERP modules, configured to real processes, so a working system is live early. This is where the majority of requirements are met, because a standard ERP already covers sales, purchasing, inventory, accounting, and reporting on shared data.

Standard configuration is the fastest and cheapest level, it is upgrade-safe, and business users can maintain it. Going live here first also gives the team a real system to work in, so training and feedback start before any custom work exists. A distributor of medical and laboratory equipment ran most of its operation, spanning more than a dozen modules, on standard configuration, which is a large part of why the full rollout went live in one quarter.

Phase 2: extend with low-code

Phase two adds the fields, views, and simple automation that settings alone cannot cover, using low-code tools that require no development. This is the level for gaps that are real but small, where the business needs an extra field on a form or a light rule to trigger an action.

Low-code changes stay fast and low cost, and they remain largely upgrade-safe, so they extend the system without the burden that custom code carries. Reaching for this level before writing code keeps a project out of the slowest phase for as long as possible.

Phase 3: build custom code for what remains

Phase three builds bespoke logic only for requirements that are unique to the business and impossible at the earlier phases. This is where genuine domain complexity is handled, and it is the right level for work that no configuration can reach.

For example, in a recent Odoo implementation for a medical distributor, custom code was reserved for the pieces the medical-import domain demanded: a custom goods-receipt note that reconciles supplier bills against received goods, a customs cost field folded into stock valuation, and documentation built to sector standards. Custom code is the most complex to build, the most expensive to own, and it adds testing to every future upgrade, so it is the last resort and the smallest phase by design.

Talk to our experts →

Why does the order matter?

The order matters because each phase controls cost, protects upgrades, and delivers working software before the most expensive work begins. Four effects follow from running the phases in sequence.

• Cost stays proportional to need. Most requirements are met in phase one at the lowest cost, so spending concentrates only on the few that reach phase three. A project that starts with custom development spends the most on work that configuration would have covered.

• Upgrades stay manageable. Phases one and two are upgrade-safe or close to it, so minimizing custom code keeps the system easy to move forward. Every line of custom code is future upgrade testing you have committed to.

• Value lands early. A working system goes live after phase one, so the business gets return before the full build is finished.

• Each phase de-risks the next. Real usage in phase one shows which low-code changes and custom builds are actually needed, so later phases are informed by evidence instead of assumptions.

Where do teams get phased launches wrong?

The most common mistake is starting with custom development for requirements that standard configuration would have covered. Teams often assume that fitting the software to the business means writing code, so they skip to phase three and inherit its cost and upgrade burden across the whole project.

A phased launch fits a business that can settle two things quickly: which system owns each record, and what each core document must contain. It also fits a business whose custom needs are limited. It works less well when a company is still deciding how it wants to operate, because every unresolved decision tends to become a custom build that a clear requirement would have avoided.

Two other mistakes recur. The first is gathering requirements as an unranked wish list, which lets scope expand to fill the schedule. The second is treating the documents a business runs on, such as invoices, delivery notes, and goods-receipt notes, as an afterthought. In a regulated operation those documents are exactly what justifies phase three.

How Redbee runs a phased launch

Redbee is an official Odoo partner and also implements SAP and Microsoft Dynamics, which supports an objective recommendation on platform and scope.

We start with what the operation already does. We map how the business runs today, so phase one is configured to real processes.

We solve at the lowest phase that works. Standard first, low-code for the gaps, custom code only for what is genuinely domain-specific. This keeps cost, timeline, and upgrade safety under control.

We build compliance and costing into the right phase. For regulated and cross-border operations, traceability, landed cost, and sector documentation are specified as phase-three requirements at the start, so they are planned rather than added under pressure.

We hand over ownership. We train users across every module so the client runs the system independently, and we stay a partner as the operation adds reporting, workflows, and further automation on the same foundation.