What to Prepare Before Building a Custom ERP

Short answer: The businesses that get the most value from a custom ERP are the ones that prepare before the build starts — with clean master data, documented workflows, and clear answers to a handful of questions about data ownership and user roles. Arriving unprepared does not prevent the build, but it does increase cost, extend timelines, and raise the probability that the finished system does not fit the actual operation.

Why Preparation Matters More Than Most Businesses Expect

A developer can only build what they understand. If the brief is vague — "we need a system to manage our inventory and customers" — the result will reflect the developer's assumptions, not the business's operational reality. Every ambiguity resolved in the brief stage costs nothing to fix. The same ambiguity discovered mid-build costs a sprint. Discovered post-launch, it costs a rebuild.

Jared Loo's experience running Terasek and an e-commerce business before entering the software side of this industry shaped a direct view: preparation is not an admin task before the real work starts. It is part of the build. Skipping it is how seven-figure technology investments end up unused.

What to Prepare: A Practical Checklist

1. Clean Your Master Data

An ERP is only as accurate as the data it starts with. Before build begins:

• Item/product master: Are all items coded consistently? Are duplicates merged? Is cost price up to date?
• Customer and supplier records: Are there duplicate entries? Are credit limits and terms recorded?
• Chart of accounts and cost centres: Are these structured to reflect how management wants to see costs?

A data cleanup exercise before build is significantly cheaper than fixing corrupt data after go-live.

2. Document Your Current Processes — Including the Workarounds

Map what actually happens, not the idealised version. If staff are sending order confirmations via WhatsApp before keying them into Excel, document that. If goods receiving is done on paper and keyed in later, document that. The workarounds reveal where the current system fails and where the new one must improve.

The system audit service includes this process mapping as a structured deliverable, which is why many businesses start there before committing to a build. The guide on what a system audit includes explains what you receive at the end.

3. Identify Your Users and Their Roles

For each role that will use the ERP, define:

• What tasks do they need to complete?
• What data do they need to see?
• What data should they not see?
• What approvals or authorisations do they handle?

This becomes the basis for access control and interface design. Building it out upfront prevents the situation where a system goes live and everyone has either too much or too little access.

4. Define Your Source-of-Truth Rules

When multiple systems hold the same data — AutoCount, a spreadsheet, a WhatsApp group, a physical stockcard — the ERP needs to become the single source of truth for at least one of them. Define which system owns each data type before build:

5. Decide on Integration Boundaries

If the ERP will sit alongside AutoCount, define exactly what the ERP owns and what AutoCount owns. Ambiguity here causes double-posting, sync conflicts, and data integrity problems. The custom ERP development service covers how to structure these boundaries in the technical design.

6. Nominate an Internal Owner

Every successful ERP project has one internal person with the authority and accountability to make decisions on behalf of the business during the build. This is not the IT manager. It is the person who understands the operations and can answer questions about how edge cases should be handled. Without this person, build decisions default to the developer's assumptions.

What You Do Not Need to Prepare

You do not need to have the perfect specification document before speaking to a developer. You do not need to know the technical architecture. You do not need to resolve every process question in advance.

What you need is honest answers to the questions above, and a willingness to map what is actually happening in the business rather than what should be happening.

FAQ

How long does the preparation phase typically take?

For a focused ERP scope — one or two operational workflows — a well-run preparation phase takes two to four weeks. Larger scope or heavily manual businesses with undocumented processes take longer. Starting with a system audit compresses this significantly because the audit does the documentation work for you.

Can we start building while still cleaning the data?

In some cases, yes — if the modules being built in Phase 1 do not depend on the data being cleaned. But if the build depends on accurate item masters or customer records, clean data needs to come first. Building on bad data produces a system with bad output, which destroys user trust quickly.

What if we do not know what we want the system to do?

That is a normal starting point and not a problem. It means the preparation work is more important, not less. A structured discovery session or system audit with an experienced developer will produce a clear brief from your operational reality, rather than asking you to invent requirements from scratch.

If you are preparing for a custom ERP build, the fastest way to get a scoped and costed plan is to start with a system audit — or WhatsApp us to describe where you are and what you are trying to solve.