Custom ERP Development Process: What Each Stage Actually Requires From You

Most guides to custom ERP development describe what the vendor does at each stage. That's only half the picture. The timeline and quality of the build depend just as much on what your team provides, decides, and shows up for. This is a practical checklist of your side of the process — what to prepare for at each stage, and what tends to slow projects down when nobody owns it.

If you're looking for how long each stage typically takes, see our realistic timeline breakdown. This article covers what you need to bring to the table, stage by stage.

Discovery: Your Job Is Honesty, Not Polish

Discovery is where the development team maps how your business actually works — not how the org chart says it works. Your responsibility here is straightforward but easy to get wrong:

• Make your process owners available. Sales, purchase, operations, and finance leads need real time on the calendar for structured interviews — not a 15-minute call squeezed between meetings.
• Describe what actually happens, not what's supposed to happen. If approvals routinely get skipped over WhatsApp, say so. A functional spec built on the official process instead of the real one will miss the workarounds your team depends on.
• Read and sign off on the functional spec properly. This document is your main protection against scope disputes later. Skimming it to "get started faster" is the single most common cause of expensive rework mid-project.

Design: Consolidate Feedback Before It Reaches the Team

Wireframes are cheap to change. Development in progress is not. Your job during design:

• Decide who has final sign-off authority. If three stakeholders each have a different opinion on a screen layout, someone needs to make the call — otherwise every review cycle reopens the last one.
• Turn feedback around within an agreed window. A design phase that should take a week stretches to a month when reviewers sit on wireframes.
• Flag anything unfamiliar now, not during UAT. If a proposed workflow doesn't match how your team actually operates, this is the cheapest point to say so.

Development: Show Up for Every Demo

Good teams build in sprints and demo working software every one to two weeks. This only catches misalignments early if someone from your side is actually testing what's shown — not just watching.

• Assign one point of contact who attends every demo and is authorised to give feedback without escalating every decision.
• Prepare your historical data early. Migration mapping — cleaning, deduplicating, and structuring years of Excel or legacy data — takes real time on your side, and starting it late is a common cause of go-live delays.
• Resist scope additions disguised as clarifications. A steady stream of "small" new requirements during development is the most common way a 10-week project becomes an 18-week one.

UAT: Test Real Scenarios, Not Just the Happy Path

User Acceptance Testing is where your team tries to break the system before your customers do.

• Assemble a dedicated testing group covering every role — not just whoever's free that week.
• Test real transactions, including edge cases: a return, a partial payment, a rejected quality check, a cancelled order. The scenarios that don't happen every day are exactly the ones that get missed if nobody tests for them.
• Separate genuine bugs from new feature requests. Both are valid, but they belong in different buckets — bugs get fixed before go-live, new features go into a scoped backlog.

Go-Live & Training: Plan the Cut-Over, Not Just the Launch

Go-live isn't a single event — it's a transition your team has to operate through.

• Schedule training by role, not as one big session. A purchase manager doesn't need to sit through a sales walkthrough, and vice versa.
• Decide your cut-over approach in advance: fresh data entry from go-live, or a full historical migration. Both are valid, but the decision affects how much data-cleaning work happens before launch.
• Appoint internal champions — one or two people per department who become the first point of contact for "how do I..." questions, so the vendor's support line isn't fielding every small query.

The Pattern Behind Every Delay

Across most delayed ERP projects we've seen, the root cause traces back to one of these on the client side: unavailable stakeholders during discovery, slow feedback loops during design and development, or an unclear sign-off chain. None of these are development problems — they're project ownership problems, and they're entirely within your control to prevent.

Ready to start? See our full custom ERP development approach or book a free discovery call →