Choose a bespoke ERP development company by examining how it will understand your processes, deliver a usable first release and support the system afterwards. A polished presentation or a low day rate cannot answer those questions. Ask for evidence that connects the proposed team, delivery method and commercial terms to the work your business needs done.
For a UK SME, an ERP supplier may become part of daily operations for years. The relationship will involve staff knowledge, customer records, integrations and decisions about change. Evaluate it as an operating partnership with clear responsibilities. The selection process should help both sides discover whether the project is suitable before a large commitment is made.
Ask for relevant experience, with enough context
Request examples involving comparable processes or technical constraints, not only companies with familiar logos. An order workflow with partial deliveries may be more relevant than an impressive project in an unrelated field. Ask what the supplier actually delivered, what remained with another team and who now supports the system.
Discuss difficulties as well as outcomes. How did the team deal with inconsistent data, unavailable integration access or changes requested during user testing? A credible explanation should distinguish planned work from discoveries and explain how decisions were made. Respect confidentiality: a redacted example or a reference conversation arranged with permission can provide useful evidence.
Do not assume a case study guarantees the same result for your business. Ask which people from the proposed team have the relevant experience and whether they will participate in your project. Record any reliance on contractors or specialist partners, including who owns the relationship and who remains accountable for delivery.
Examine the discovery deliverables before approving the build
A discovery phase should reduce uncertainty and leave something you can use. Ask for a process map, prioritised scope, integration assessment, data findings, proposed first release and an estimate with assumptions. Agree which questions must be answered before the next phase and what happens if the evidence suggests a different approach.
The supplier should be willing to discuss standard products, extensions and improvements to your current system. Custom development is a means to a business outcome, so it needs a reason. Our ERP build-or-buy guide offers a way to compare those options before committing to the implementation path.
Provide enough access to make discovery useful. Nominate process owners, prepare representative records and make time for decisions. Ask the supplier to distinguish assumptions from verified facts in its findings. A fixed build price based on inaccessible data and untested integrations deserves closer examination, even if its presentation looks reassuringly precise.
Check how delivery and acceptance will work
Ask to see how requirements become demonstrable outcomes. A useful delivery plan identifies who reviews each increment, which users test it and how defects are distinguished from new scope. Your team should regularly see working software with representative data, rather than waiting for a final presentation after most of the budget has been spent.
Agree acceptance criteria for business results and operational behaviour. For an order module, include exceptions, permissions, traceability and the integration handover. Define how performance and recovery are assessed at the scale relevant to your company. Avoid accepting a milestone solely because a list of screens exists.
The UK government's Contracting for Agile guidance discusses aligning commercial arrangements with iterative delivery. It is public-sector guidance; use the relevant ideas as questions for your supplier, rather than assuming public procurement rules apply to your SME. Make spending authority, progress reporting and changes in scope explicit in your own agreement.
Make source code and operational ownership specific
Ask what rights the contract grants over source code, documentation, configuration and future modifications. Identify pre-existing supplier components, open-source dependencies and commercial licences separately. Do not assume paying an invoice automatically provides every right or asset needed to move the system. Have the relevant contractual terms reviewed for your circumstances before signing.
Request a practical handover definition. It should identify repositories, build instructions, deployment configuration, environment information and operational documentation. Clarify who controls cloud subscriptions, domains and administrative accounts. Access should be appropriate to each responsibility and recoverable if an individual leaves the project.
A useful test is whether another authorised team could build, deploy and support the application using the delivered material. Ask when this will be demonstrated and how documentation stays current. A ZIP of source files at the end of the project is a limited handover if the working system depends on undocumented services or personal accounts.
Review migration and cutover as real work
Ask who identifies data to move, resolves quality problems and approves reconciliation. The proposal should include representative trial imports, a cutover sequence and acceptance checks appropriate to the records involved. Historic data may need migration, archiving or continued consultation; those are decisions to make with business owners, not assumptions to leave until launch.
Discuss the period when old and new systems coexist. Who enters new orders, where do users check status and which system is authoritative? Explain how integrations behave during the transition. If both systems can change the same records, the plan must address reconciliation rather than simply expecting people to remember which screen to use.
Ask what would stop the cutover and what would trigger a return to the previous arrangement. The answer should explain treatment of transactions created since the switch. A rollback that loses new business records is not equivalent to restoring normal operation. This is a useful topic for evaluating the supplier's practical delivery judgement.
Assess security and the support team behind the proposal
The NCSC's supply-chain security principles provide a reference for reviewing supplier assurance. Ask how the team controls access, handles secrets, reviews changes and reports security incidents. Where a certification is offered as evidence, check its scope and current status against the services you are buying.
Discuss how subcontractors and cloud services fit into the arrangement. Your question is who is responsible for the delivered system and how issues are coordinated. Ask for an example of the incident process, including customer communication and the handover from investigation to corrective work. Technical competence should be supported by a clear way to act under pressure.
For UK business operations, establish working hours, public-holiday coverage and escalation for urgent problems. Distinguish an initial response from restoration and permanent resolution. Ask what happens when the main developer is unavailable, how knowledge is shared and which maintenance activities are included. A named contact is useful; a support process that depends entirely on one person is fragile.
Compare the quote and choose a controlled first commitment
Give shortlisted companies the same brief and ask for comparable cost categories. Confirm currency, VAT treatment, payment milestones, dependencies, expenses, support charges and exclusions. Ask how estimates change if an integration assumption proves wrong. Our ERP cost guide explains how to make the first-phase budget easier to inspect.
Choose a first commitment that produces evidence: a scoped discovery, a difficult integration trial or a pilot of one complete process. Agree the decision at its end and the material you retain if you stop. A good supplier relationship starts with clear outcomes and enough visibility for both sides to make informed choices.
Worktechlabs can help define and deliver bespoke ERP systems, connect existing tools through integrations and plan ongoing support. Tell us about your project, including the process causing the most friction and the systems you need to keep. We can discuss a first phase, its deliverables and the support responsibilities that should be clear before development begins.
Official sources and further reading
