Bespoke ERP development in the UK does not have a reliable single price. The useful number is the cost of a defined first release, with its integrations, data migration and operating responsibilities included. A quotation for an order-processing module cannot be compared fairly with one that also replaces purchasing, inventory and finance.
For a business owner, the first budgeting decision is therefore what must improve first. Perhaps staff rekey approved quotations, orders disappear between departments, or reporting takes days. Describe the expensive interruption and the result you need. That gives a supplier something concrete to estimate and gives you a way to judge whether the investment is worthwhile.
What determines the development budget?
Count business rules before screens. A simple order form may require customer-specific pricing, approval limits, credit checks, stock reservations and different treatment of returns. Those rules influence implementation and testing even when the interface looks small. Provide examples of ordinary transactions and exceptions so the estimate reflects the work your team actually performs.
Integrations create another major variable. Connecting to a documented, accessible accounting API differs from exchanging files with an older application that only one person understands. Ask the supplier to identify each connection, its owner, available test access, licensing conditions and failure behaviour. “ERP integration included” needs a defined direction, frequency and set of records.
Also specify service expectations. A system used during office hours has different operational needs from a platform that must accept orders overnight. User numbers matter, but simultaneous activity, attachment volumes and recovery requirements can matter more. Ask which assumptions would change the price if your company grows or adds another operating site.
How large should the first ERP module be?
Choose a complete business journey that a small group can use in real work. For a hypothetical distributor, phase one could take an approved order through allocation, picking and dispatch confirmation, while retaining the existing accounting package. The module must handle exceptions within that journey, including cancelled orders and partial deliveries, rather than only demonstrating the happy path.
Write down exclusions with equal care. Supplier purchasing, advanced forecasting and replacing the finance ledger might wait. Clarify how users complete those activities during the pilot and which information crosses between systems. A smaller release is useful only when the remaining manual work is understood and manageable.
Before commissioning custom functionality, compare the process with existing products. Microsoft describes fit-to-standard analysis before assessing custom extensions in its Dynamics 365 implementation guidance. The buying question is practical: which requirements justify ongoing bespoke maintenance, and which can be met through configuration?
A worked budget example, with explicit assumptions
The following is an invented planning exercise, not a Worktechlabs quotation, a UK market average or a promised delivery schedule. Suppose a tightly bounded first module has one integration, three user roles and an agreed set of migration files. Imagine the estimate allocates ten person-days to discovery, thirty-five to development, ten to migration, fifteen to testing and five to release and training.
That totals seventy-five person-days. Using a purely illustrative blended rate of £600 per day produces £45,000. A separately agreed fifteen per cent contingency would add £6,750, making the example allowance £51,750 before VAT, hosting, third-party licences and your internal staff time. Replace every input with evidence from your own proposal; the arithmetic is the lesson, not the rate.
Person-days are effort, not elapsed calendar days. Reviews, access to external suppliers, user acceptance and staff availability affect the schedule. Ask what the contingency covers, who can authorise its use and whether unused allowance is payable. A quote that shows these assumptions is easier to manage than a headline price with an undefined list of extras.
What data will have to move?
Start with records needed to operate the first module: active customers, products, relevant prices, open orders and any balances or stock positions it relies on. Historical records may need migration, an archive or continued read-only access. Decide this by business use rather than assuming every old table belongs in the new system.
Budget for mapping, cleaning, trial imports and reconciliation. Someone in your business must resolve duplicate customers, obsolete product codes and inconsistent units. A developer can build an import, but cannot reliably guess which of two contradictory addresses is correct. Microsoft's data management guidance highlights the role of data quality and business ownership.
Require a rehearsal using representative data and a written acceptance check. For example, compare counts of open orders and agreed monetary totals, then inspect selected records with attachments and unusual statuses. Define when old-system entry stops, who approves the cutover and what happens to transactions created during any reversal. These activities belong in the estimate.
Which costs continue after launch?
Separate the build from the monthly and annual operating budget. Include application hosting, database capacity, backups, monitoring, third-party services, support and planned maintenance. Check whether development and test environments are included. A low production hosting figure can hide costs elsewhere if each connection requires another subscription or separate environment.
Support and development are different commitments. Ask whether the support fee covers incident diagnosis, restoration, security updates and dependency upgrades, or only access to a helpdesk. Establish the hours covered, escalation arrangements and treatment of out-of-hours work. New features, changes requested by users and significant platform upgrades may have separate estimates.
For cloud costs, use a model that changes with expected usage instead of treating the first month's bill as permanent. Microsoft's cost modelling guidance provides a useful structure. Ask your supplier for expected operating cost at today's volume and at an agreed growth scenario, together with the assumptions behind both.
Compare proposals on the same basis
Give shortlisted suppliers the same process description, sample data, integration list and acceptance criteria. Ask each to separate discovery, implementation, migration, testing, launch and support. Request explicit treatment of VAT, travel, expenses, licence renewals and changes in scope. For a UK business buying services priced in another currency, also agree how exchange-rate changes affect the quote.
Do not judge value only by the day rate. A proposal should identify deliverables, dependencies, payment milestones and the evidence required to accept each stage. Ask what happens if an integration proves unavailable, who owns completed work and what information another provider would receive if you change suppliers. These questions make the budget usable as a management tool.
Worktechlabs can help define a bespoke ERP first phase, assess existing-system integrations and turn a broad idea into a scoped proposal. Bring one process that is costing time, examples of its exceptions and a list of systems involved. Discuss your ERP project with that evidence, and the conversation can focus on a manageable first investment and the responsibilities that follow it.
Continue planning your ERP project
Before committing to a build, use our bespoke ERP versus off-the-shelf guide for UK SMEs to compare the alternatives. Once you have a viable first scope, the phased ERP rollout guide explains how to manage migration and keep the business operating during the change.
Official sources and further reading
