# Custom ERP for small business: build or buy?

Decide whether to configure, buy or build software. Map workshop requirements, test errors and recovery, and plan who maintains the finished system.

By Daltn editorial team. Published 2026-11-01.
Canonical: https://daltn.tech/feeds/daltn-vs-custom-erp-small-business/

## When should a small business commission custom ERP?

Custom ERP can suit a small business with specific operational requirements and resources for implementation, maintenance and continued support. Define the controls and handoffs the system must handle before comparing configuration, specialist products and a custom build. Use a narrow pilot to test corrections, duplicate requests and recovery alongside the normal workflow.

## Keep these in mind

- Custom software can be justified by specific requirements, not by company size alone.
- Implementation includes data, process ownership and maintenance as well as screens.
- Choose a system only after testing the business controls the process requires.

Requirement | Evidence required | Candidate to evaluate
--- | --- | ---
Capture a changed finish | Reviewed source and affected job | Shared customer and job information
Reserve material | Authoritative quantities and movement controls | Inventory or ERP system
Schedule preparation | Owner, work time and deadline | Work-planning system
Post financial effects | Approved accounting treatment | Accounting system
Unique production logic | Documented rules and correction paths | Configured or custom application

## Write the requirement behind “we need an ERP”

A workshop might need to reserve materials, track production stages, handle approved change orders and report financial results. Those are several connected responsibilities. Before asking anyone to build software, describe the decisions, records and controls involved in each responsibility.

The phrase “one system” can hide missing detail. A screen showing stock does not establish how stock movements are authorized or corrected.

A screen showing money does not establish accounting capability. List the evidence needed to trust the record, including who can approve changes and how the team investigates a mistake.

## Compare implementation work, not a guessed price

[Odoo’s implementation methodology](https://www.odoo.com/documents/content/nElGuToBRwODc2Z6F9gHpwo2e674) is a useful primary reference for thinking about implementation as a project involving process and data decisions. Your actual scope, existing data and ownership will determine the work. A universal price such as “every small ERP costs this much” would be misleading.

Some needs can be met by improving how everyday updates reach a shared record. Others require stock controls, accounting treatment or a carefully defined production process. Separate those requirements before asking for a build.

Start with a smaller scope. Test whether configuration meets the requirement before committing to custom development.

## Map a workshop requirement before choosing a build

In an illustrative workshop, a customer approves 24 desks, then changes six units to a different finish. The change may affect materials, cost, work instructions and delivery.

A conversational update can capture the request. Define how each affected system accepts and applies the change.

Use the matrix as a requirements exercise. Ask each prospective solution to demonstrate the responsibility assigned to it, using a real example and a correction.

Keep the requirements separate during evaluation. Check the controls the business depends on alongside the quality of the screens.

## Require a complete handover package

Before commissioning custom work, agree on who receives the process documentation, configuration and recovery instructions. Decide how a new maintainer would understand a changed field or business rule. Ask the builder to show that handover on the pilot workflow.

A useful application remains operable when its creator is unavailable. Document the knowledge another maintainer needs.

## Test the hard parts before building every screen

When several records must change together, transaction behavior matters. [PostgreSQL’s transaction tutorial](https://www.postgresql.org/docs/current/tutorial-transactions.html) explains atomic changes and commit or rollback as general database concepts.

Ask the builder what happens if an order saves but its related stock movement fails. The business needs an understandable recovery process, not just a successful demonstration of the happy path.

Ask a prospective builder to demonstrate a partial failure, a duplicate request and a correction. Name who maintains the system after handover and how data can be recovered or exported. A workshop should understand these responsibilities before committing to a broad build.

1. List the records and approvals needed for one complete job.
1. Separate current must-haves from future ideas and visual preferences.
1. Inspect suitable off-the-shelf or configurable systems before commissioning custom work.
1. Pilot one difficult change through capture, approval, downstream updates and correction.
1. Agree who owns maintenance, data migration, documentation and support.
1. Expand only after the pilot demonstrates the required operational controls.

## Common questions

### When can custom ERP be appropriate for a small business?

It can be appropriate when important requirements are specific and the business can fund implementation, maintenance and support. Define those requirements and compare configuration options before commissioning a broad build.

### What should a custom-software handover include?

Include process documentation, configuration, recovery instructions and a named maintenance owner. Ask a new maintainer to explain a changed business rule and demonstrate how an error can be corrected.

## Sources

- [Odoo Implementation Methodology](https://www.odoo.com/documents/content/nElGuToBRwODc2Z6F9gHpwo2e674): Implementation planning, configuration and migration considerations.
- [PostgreSQL documentation: Transactions](https://www.postgresql.org/docs/current/tutorial-transactions.html): Atomic changes, commit and rollback as general database concepts.