Custom ERP or existing software: when to build

Separate process problems from software gaps

Repeated copying, missing approvals, and inconsistent records can indicate a software gap. They can also indicate that ownership or process rules have not been agreed. Map a real order, purchase, or approval from start to finish before selecting a system.

Record the people involved, data needed, states, exceptions, and decisions. If two teams disagree about the meaning of an order status, a new application will preserve that disagreement unless the rule is resolved.

Evaluate configuration and integration first

Existing ERP or business software may cover common workflows. Compare its actual fit with your requirements, including roles, reports, migration, integrations, and recurring charges. An integration or small custom module can sometimes solve the problem without replacing a useful core system.

Build custom modules around stable differences

Custom development becomes more useful when the workflow is distinctive, understood, and important enough to justify ongoing ownership. Begin with a bounded module such as inventory movement or purchase approvals rather than an undefined requirement to replace everything.

• Name the owner of each record and workflow
• Identify the source of truth for each field
• Define permissions, approvals, and exception handling
• List migration sources and data-quality issues
• Agree acceptance criteria for the first module

Plan the transition, not just the application

Choose a limited pilot, reconcile imported records, and train the people who operate the workflow. Decide how long old and new systems run together and who can authorize the switch. Backup and rollback responsibilities should be explicit.

Evaluate the first release using observed measures such as missing records, time spent reconciling data, or approval turnaround. Do not assume revenue or efficiency gains before the team has used the system and established a measurement basis.