15 Questions to Ask Before Hiring an ERP Development Partner

You have been through the vendor selection process. You have compared options, evaluated approaches, and narrowed the field. Now you are in the decision stage of the buying journey. There is a contract on the table, and a partner is waiting for your signature.

This is where most buyers get it wrong. By this point, the sales relationship is comfortable, the proposal looks polished, and there is pressure to move forward. The instinct is to sign and start the project. But a few well-chosen questions can reveal whether your partner is genuinely trustworthy, or whether they are relying on the momentum of the deal to paper over risks that will surface later.

The stakes are high. A poorly chosen ERP development partner can cost you six figures in overruns, leave you with software you cannot maintain, and delay your digital transformation by years. According to a 2023 report from McKinsey, 66 percent of large-scale software projects exceed their budgets, and 33 percent fail to deliver against their original scope. The common thread in these failures is not bad technology — it is a bad partnership that was never properly vetted.

The 15 questions below are not designed to trip up a vendor. They are designed to surface the truth. A good partner will welcome them, answer them directly, and strengthen your confidence. A partner who hedges, deflects, or refuses to answer is telling you everything you need to know.

We have grouped them into three categories. The commercial questions cover pricing, IP ownership, contract terms, and insurance — the structural safeguards that protect your investment. The technical questions cover technology stack, API integration, security, data migration, and ongoing maintenance — the operational realities that determine whether the software actually works. The relationship questions cover team composition, references, code access, and communication — the human factors that determine whether the partnership is sustainable.

Ask every single one before you sign. And listen carefully to what the answers reveal about their attitude, their process, and their willingness to be transparent.

---

Q1: "Can You Show Us a Real Project Like Ours?"

This is the easiest question to ask and the hardest to fake. You want to see a case study involving an ERP system comparable to yours, with a scope and complexity similar to what you need.

Do not be impressed by a portfolio of mobile apps or e-commerce sites if you are buying an ERP integration project. The technical challenges are fundamentally different: ERP integration demands deep understanding of OData APIs, rate limiting, idempotent write operations, data consistency, and business logic that spans multiple entities. A partner who has only built marketing websites does not know what they do not know.

What a good answer sounds like:

• The partner names the client, the ERP, the challenge, and the outcome.
• They share specific details: timeline, budget vs actual cost, technologies used, team size.
• They offer to put you in touch with that client as a reference.
• They acknowledge areas where the project was difficult and how they adapted.
• They can walk you through the architecture decisions they made and why.

What to watch for: Vague case studies with no client name. "Commercially sensitive" excuses. A single case study that is ten years old. Case studies involving different technology entirely. A Shopify storefront does not prove ERP capability. Neither does a CRM integration project.

If they cannot show you something genuinely comparable, ask yourself why. Either they lack relevant experience, or they are not confident enough in their past work to let it speak for itself.

Q2: "Who Owns the Intellectual Property?"

You are paying for custom software to be built for your business. The intellectual property in that code should belong to you. Without this, you are locked in forever.

What a good answer sounds like:

• "You do. Full IP assignment on payment."
• "You receive the source code, all documentation, and deployment credentials on go-live."
• "There are no ongoing licence fees for the software we build."

What to watch for: "We retain a perpetual licence to reuse the code." "You get a licence to use the software." "Our framework is proprietary, so you only licence the overlay." Any answer that does not include "you own it" without qualification.

If the partner wants to resell what they build for you, negotiate a discount in exchange, but do not accept shared ownership by default. You pay; you own.

Q3: "What Is Your Pricing Model?"

There are two dominant pricing models in custom software development: fixed-price and time-and-materials (T&M). Each carries different risk for you as the buyer.

Fixed-price: The partner quotes a single price for a defined scope. You pay that price regardless of how many hours it takes. This is good for cost certainty but bad if the scope changes. Partners who quote fixed-price for fuzzy scope are either padding aggressively or setting themselves up to argue about change requests.

Time and Materials: You pay for actual hours at an agreed rate. Scope can flex, but the final cost is unknown until the project ends. This works well for discovery and iterative work, but poorly for buyers who need a budget.

What a good answer sounds like:

• "After a short discovery sprint to scope the work, we quote a fixed price for a clearly defined build phase."
• "Changes to scope are handled through a transparent change control process with agreed rates."
• "We share our day rates and estimated hour ranges so you understand what you are paying for."

What to watch for: "We only work T&M, no fixed quotes." Or, "The price is fixed but the scope is flexible" (contradictory and dangerous). Also watch for hidden costs: hosting setup fees, migration charges, "integration surcharges."

Q4: "What Happens If the Project Overruns?"

Every project hits unexpected complexity. The difference between a good partner and a bad one is how they handle it.

What a good answer sounds like:

• "We have a change control process: you submit a change request, we estimate it, you approve it, we build it. Costs are agreed in advance."
• "We build in a contingency buffer (typically 10-15 percent) so minor surprises do not trigger a change request."
• "We flag risks early, usually within the first sprint if we spot scope ambiguity."

What to watch for: "There are no overruns because we padded the estimate" (you are paying for that padding whether you need it or not). "We absorb the first two weeks of overrun" (generous-sounding, but it means scope slippage is expected). "That rarely happens" (it always happens).

Q5: "What Technology Stack Do You Use?"

The technologies your partner chooses determine your long-term maintenance costs, your ability to hire developers, and your vulnerability to platform deprecation.

This is not about picking the trendiest framework. It is about picking a technology that has a deep hiring pool, strong community support, a clear upgrade path, and a track record of being used in production ERP-adjacent applications. In 2026, the safe choices are clear: React or Next.js for the frontend, TypeScript for type safety, Node.js or Python for the API layer, and PostgreSQL or a managed cloud database for persistence.

What a good answer sounds like:

• Mainstream, well-supported technologies: React, Next.js, TypeScript, Node.js, Python, PostgreSQL, or similar.
• They explain why they chose each technology, not just the name.
• They acknowledge trade-offs honestly (e.g., "We use React over Vue because of the hiring pool, but Vue is also fine").
• They can describe their testing strategy, deployment pipeline, and monitoring approach.

What to watch for: Obscure frameworks. Proprietary "platforms" that lock you into the vendor. "We built our own low-code platform" (ask hard questions about what happens when you want to leave). Technologies that are hard to hire for (COBOL, Delphi, ColdFusion are red flags). No mention of testing or CI/CD at all.

Mainstream tech matters because your code should be maintainable by someone other than the original developer. If your partner goes bust, your code should not become unmaintainable.

Q6: "How Do You Handle Our ERP's API?"

Your ERP exposes data through an API, but APIs have quirks: rate limits, versioning, inconsistent response schemas, write-back limitations. Your partner should have a clear strategy for managing these.

What a good answer sounds like:

• "We use an adapter pattern: a dedicated service layer that translates between the ERP API and your application. If the API changes, only the adapter needs updating."
• "We handle rate limiting with exponential backoff and request queuing."
• "We pin to a specific API version and test against new versions before migrating."
• "We audit your ERP's API endpoints during discovery to identify gaps before build."

What to watch for: "We connect directly to the database" (dangerous, breaks your ERP support contract, and Microsoft explicitly warns against it). "The API is fine, we can just call it directly" (naive about rate limiting, versioning, and error handling).

Q7: "What Ongoing Support Do You Provide?"

Software is never finished. After go-live, you will need bug fixes, security patches, feature updates, and help with unexpected issues. How that support is structured matters.

What a good answer sounds like:

• "We offer a monthly support retainer or subscription that covers hosting, security patches, maintenance, and a certain number of support hours."
• "SLA-defined response times: critical issues within 4 hours, standard within 24 hours."
• "We can also work ad-hoc if you prefer to handle support internally and only call us for changes."

What to watch for: "We do not do support" (you will need it). "Support is billed at our standard day rate with no SLA" (expensive and unpredictable when things break). A mandatory multi-year support contract with no termination option.

Q8: "Can We Terminate the Contract?"

No buyer signs up expecting to terminate early, but the termination clause tells you about the power balance in the relationship. A fair contract lets both sides exit.

What a good answer sounds like:

• "You can terminate for convenience with 30 days' notice."
• "On termination, you receive all source code, documentation, deployment credentials, and any third-party accounts."
• "There is no early termination fee beyond paying for work completed."

What to watch for: "You cannot terminate until the project is complete" (what if completion never comes?). "IP is transferred only after final payment" (standard, but check what happens if you part ways mid-project). "Ongoing subscription fees continue regardless of termination" (a trap).

Q9: "What Security Certifications Do You Have?"

You are trusting this partner with your ERP data, which includes customer records, financial data, pricing, and operational information. Security certification demonstrates that security is not an afterthought.

What a good answer sounds like:

• "We hold Cyber Essentials certification." (Minimum standard for UK businesses.)
• "We are working toward ISO 27001 or SOC 2."
• "We undergo annual penetration testing and share the executive summary with clients."
• "All infrastructure is hosted in UK or EU regions with data residency guarantees."

What to watch for: "We take security very seriously" (unaccompanied by any certification or audit). "Security is handled by our hosting provider" (the provider secures the infrastructure, not your application). "We cannot share our penetration test results" (red flag; you should at least see a summary).

For UK manufacturing and distribution businesses handling personally identifiable information or commercially sensitive data, Cyber Essentials certification should be non-negotiable.

Q10: "Who Will Be Working on Our Project?"

The people you meet during the sales process may not be the people who build your software. You need to know who is actually doing the work.

What a good answer sounds like:

• "You will meet the team during the proposal stage. Here are their names and backgrounds."
• "We use a dedicated team model: the same people work on your project throughout."
• "If we need additional capacity, we tell you in advance and introduce any new team members."

What to watch for: "Our senior architect designs the solution, and our offshore team builds it" (you may never meet the people writing your code). "We use freelancers as needed" (variable quality, no accountability). "The team may change depending on availability" (your project gets whoever is free that week).

If the partner uses subcontractors or offshore developers, there is nothing wrong with that, but you have a right to know. Ask about how code quality is assured across distributed teams.

Q11: "How Do You Handle Data Migration?"

This question is partially a trap. A good answer may surprise you.

What a good answer sounds like:

• "We do not migrate your data. We connect to your ERP via its API and operate on the live data in place."
• "There is no duplicate database. Your data stays in your ERP. The interface layer reads and writes through the API in real time."
• "If you ever want to move to a different ERP, only the integration adapter needs rewriting. Your frontend applications do not change."

What to watch for: "We will migrate your data into our platform" (now you have a data residency problem, a sync problem, and a lock-in problem). "We need a copy of your database for performance reasons" (ask about caching strategies instead). "Migration is included in the fixed price" (where is the data going, and why?).

Data migration is the single biggest risk in any ERP project. Avoiding it is not lazy, it is smart. The best interface-layer approach does not move your data at all.

Q12: "What Happens When Our ERP Updates?"

Your ERP vendor pushes updates on their schedule, not yours. Microsoft releases two major updates per year for Business Central (one in April, one in October). Sage 200 updates on a less predictable cadence. NetSuite pushes quarterly releases that sometimes include API changes. If your interface layer breaks after an update, you have a problem that can halt operations.

The response to this question reveals whether the partner has real-world experience with live ERP integrations, or whether they are assuming nothing ever changes.

What a good answer sounds like:

• "We monitor ERP API changelogs and test against preview versions before updates go live."
• "We pin to specific API versions and migrate deliberately when a new version is stable, never blindly."
• "Our adapter pattern means an API-breaking change only requires the adapter layer to be updated, not the entire application."
• "We have a notification process with your ERP team: they tell us about upcoming update windows, and we validate compatibility ahead of time."
• "Our subscription includes ongoing API monitoring and proactive compatibility testing."

What to watch for: "ERP updates rarely break our integrations" (they do, and anyone who says otherwise has not operated a production integration through a full upgrade cycle). "We will fix it if it breaks" (without a defined SLA, you could be waiting days or weeks). No awareness of the specific update cadence of your ERP.

Q13: "Can We See the Code?"

If you own the intellectual property, you should be able to see the code at any time during the project, not just at the end.

What a good answer sounds like:

• "Of course. You have read-only access to the repository from day one."
• "We use GitHub or GitLab. Your team gets access to view commits, pull requests, and the issue tracker."
• "We do code reviews including your developers if you have them."

What to watch for: "We do not share the repository during development" (why not?). "You will receive the code at the end" (too late to catch problems). "Our platform does not expose the underlying code" (you do not really own it).

Transparency during development builds trust and lets your internal team (or an independent consultant) verify progress and quality.

Q14: "Do You Have Professional Indemnity Insurance?"

If the software your partner builds causes financial loss, professional indemnity (PI) insurance covers the claim. Without it, you have no recourse if something goes catastrophically wrong.

What a good answer sounds like:

• "Yes, we hold professional indemnity insurance with a minimum of £1 million in cover."
• "We can provide our insurance certificate and policy details."
• "We also hold public liability insurance."

What to watch for: "We do not carry PI insurance because we are a small consultancy" (size is not an excuse). "Our parent company covers us" (ask to see the certificate). "We have never needed it" (that is not how insurance works).

For any project involving live ERP data, PI insurance is not optional. It is a minimum threshold for being taken seriously as a professional services firm.

Q15: "What References Can You Provide?"

If a partner cannot produce at least three recent, relevant client references who are willing to speak with you, that is a significant warning sign.

What a good answer sounds like:

• "Here are three clients in similar industries. You can call them directly."
• "We have prepared a reference list with named contacts, phone numbers, and project descriptions."
• "One of our references is happy to take a call and show you the system live."

What to watch for: "All our clients are confidential" (too convenient). "We can provide written testimonials" (not the same as a phone call). "The references are in a different industry" (the partner is telling you they lack relevant experience without saying it directly).

When you call the reference, ask specific questions: Did the project come in on budget and on time? What went wrong? Would you hire them again? What would you change about the relationship?

---

Red Flags to Watch For: Summary Table

How to Use This Checklist Effectively

Print or bookmark this list. Go through it systematically in your next vendor meeting. Do not send the questions by email in advance — ask them in person or over a video call where you can observe how the partner responds. Hesitation, vagueness, and deflections are easier to spot in conversation than in a written reply.

If the partner offers to put you in touch with past clients, take them up on it. Call those references and ask the hard questions: was the project delivered on budget? What went wrong? Would you hire them again? What do you wish you had asked before signing?

And finally, trust your instincts. A partner who is transparent, confident, and direct about their limitations is far safer than one who promises everything and deflects every question. ERP development partnerships last years, and the decision stage is your only chance to get the balance of power right.

---

Frequently Asked Questions

1. Should I use a large systems integrator or a smaller specialist?

Large integrators (Accenture, Deloitte, KPMG) offer brand reassurance and deep benches, but your project may be a small fish in a large pond. Smaller specialists typically offer more senior attention, faster decision-making, and lower overheads. The right choice depends on project complexity. For a focused interface-layer build, a specialist is usually a better fit because the problem does not require hundreds of consultants.

2. How long should a discovery sprint take?

A thorough discovery sprint for an ERP interface project typically takes three to five days. It should include on-site observation, API audit, user interviews, and a fixed-price proposal. If the partner wants to skip discovery and go straight to build, that is a red flag. If they want more than two weeks for discovery, they may be unsystematic or billing for thinking time.

3. What should the contract include?

At minimum, the contract should specify: scope of work (clearly bounded), fixed price or rate card, payment milestones, change control process, IP assignment clause, termination terms, data protection provisions (GDPR-compliant), confidentiality obligations, and liability caps. If any of these are missing, ask why.

4. Can my internal IT team maintain the code after handover?

That depends on the technology choices and the quality of documentation. If the partner uses mainstream technologies (React, TypeScript, Node.js), your team can probably maintain it with reasonable training. If they use a proprietary platform or an obscure framework, maintenance becomes expensive or impossible without the original developer. Ask about documentation standards before signing.

5. What is a reasonable timeline for a custom ERP interface?

A single-role staff dashboard typically takes 4–6 weeks from discovery sign-off. A customer self-service portal with read-only access takes 6–8 weeks. A full platform with staff dashboards, customer portal, and management reporting takes 10–12 weeks. If a partner quotes three months for a simple dashboard, they may be inexperienced or padding. If they quote two weeks for a full portal, they do not understand the complexity of ERP integration.

6. What level of access should my internal team have during the build?

Your internal team should have access to the project management tool, the code repository (read-only at minimum), and regular sprint demos. You should be able to see progress in real time, not just through monthly status reports. Weekly sprint reviews are standard. If the partner treats the build phase as a black box and promises to deliver a finished product at the end, that is a significant risk. Software development is inherently uncertain, and regular visibility is your only way to catch problems early.

7. How should payment milestones be structured?

Payment should be linked to demonstrable deliverables, not calendar dates. A typical structure for a fixed-price project is 50 percent on signature (to fund the initial build), 25 percent on delivery of the core functionality (staff dashboard, API integration), and 25 percent on go-live and IP transfer. Avoid payment schedules that front-load payments before significant work is delivered. And never accept a structure where 90 percent is due before you have seen and tested the working software.

---