How to Choose a Software Partner for Your ERP Project — 10 Questions to Ask

Selecting technology for your ERP project is only one side of the equation. The other side is deciding who builds it with you.

Technology alone does not implement a project — software engineers do. And therein lies the rule for investing in custom software: your choice of partner determines whether your outcome trends toward success or failure.

A poorly selected software partner who takes the wrong architectural decisions can deliver late code, riddled with technical debt, leaving you trapped in a contract that costs more than the software itself should have. A well-chosen partner minimises business risk through transparency, modular architecture, and modern, widely understood technologies. The cost of rework and rediscovery may dwarf the original build cost.

The challenge is that most buyers of software services lack the methodology to evaluate one supplier against another. Proposals all look similar. Every partner claims to be “trusted” and “experienced.” Without a structured approach, you end up choosing based on price or personality — two of the worst criteria for a decision this important.

This article offers a structured list of 10 questions that will separate a reliable partner from one you should avoid. Use these questions to evaluate your options, and share them with your procurement team to build a proper scoring matrix.

Whether you are a finance director, operations manager, IT director, or CEO, these questions apply equally. The technology supplier you choose will be embedded in your business operations for years to come. Getting the selection wrong costs far more than the contract value — it costs time, team morale, and competitive advantage.

We have seen procurement processes that focus almost entirely on price per day or total project cost. While budget matters, the cheapest partner is rarely the most cost-effective over the full lifecycle of the software. A partner who cuts corners on discovery, uses obscure technology, or retains your intellectual property will cost you far more in the long run than one who charges a fair price for a well-structured engagement.

Let us get into the specific questions you should ask every potential partner, and the answers that separate the trustworthy from the risky.

---

1. “Do you start with a discovery phase or jump straight into building?”

The single strongest indicator of a mature partner is whether they recommend a discovery sprint before any build activity. A partner who agrees to estimate price without first understanding your workflows is making assumptions that will inevitably cost you later.

A proper discovery sprint typically lasts three to five days and includes:

• On-site observation of how your team actually works vs how the process document says they work
• Mapping of current pain points and bottlenecks
• API audit against your existing ERP system to validate data availability
• Wireframes or UX concepts for the proposed solution
• A detailed scope document that forms the basis of a fixed-price proposal

Why a paid discovery sprint is a green flag, not a red flag. Many procurement teams instinctively push back against paid discovery. They see it as a consulting upsell. In practice, a paid sprint aligns incentives: you are paying for the partner’s time to understand your business properly, which means the resulting estimate is accurate and the risk sits with them, not you.

A free proposal, by contrast, is typically based on surface-level assumptions. The partner has no skin in the game. They give you a number that sounds plausible and then rely on change requests to make the economics work later.

Expected answer from a good partner: “Yes, we recommend a paid discovery sprint. It de-risks the project and lets us give you an accurate fixed price. If we proceed to build, the sprint fee is deducted from the build cost.”

2. “Do you use fixed-price or time-and-materials contracts?”

Time-and-materials (T&M) contracts transfer all project risk to you, the buyer. The partner bills by the hour, and the final cost depends entirely on how long the project takes. If the partner underestimates, you pay the difference. If requirements change, you pay for every additional hour. There is no incentive for the partner to be efficient.

Fixed-price contracts, by contrast, put the risk on the partner. They estimated the work; they commit to deliver it for that price. If they encounter unforeseen complexity, they absorb the cost — not you.

The objection you will hear from T&M advocates is that “software is too unpredictable for fixed price.” That is true only when the partner skips discovery. With a proper discovery sprint, the scope is well enough understood to price accurately. The residual uncertainty is small and manageable.

Expected answer from a good partner: “We work fixed-price after a discovery sprint. The scope document from discovery defines exactly what we will build, and we commit to delivering it for that price. Changes to scope are re-priced separately.”

3. “Who owns the intellectual property?”

This is the most important legal question in any software engagement — and the one buyers most frequently overlook. You must own the code. Not a licence to use it. Not shared ownership. Full, unrestricted ownership of the source code, the design assets, the documentation, and all intellectual property created during the project.

Some partners retain IP ownership and grant you a licence to use the software. This creates a trap: if you ever want to switch partners, you cannot take the code with you. You are locked in. The partner can charge you whatever they like for ongoing maintenance because you have no alternative.

Red flag: The partner claims they “retain IP” because they use “proprietary frameworks” or “reusable components.” This is a smoke screen. Any decent partner can separate genuinely reusable internal tooling from your application code. You should own everything that was built specifically for you.

The IP clause should be explicit in your contract. Do not accept vague language like “the client receives a perpetual, irrevocable licence to use the software.” That is not ownership — it is permission. Insist on language that says: “All rights, title, and interest in the deliverable code, design assets, and documentation vest in the client upon payment.” Have your legal team review this clause specifically. It is the single most important protection in the entire agreement.

Also ask about third-party components. The partner should disclose any open-source libraries or commercial components they use and confirm that their licensing is compatible with your ownership of the overall application. GPL-licensed code, for instance, can create complications for proprietary software.

Expected answer from a good partner: “You own the IP. Full assignment of source code, design, and documentation upon payment. We do not retain any rights to your application code. Our standard contract includes a clean IP transfer clause.”

4. “What happens if we want to stop working with you?”

No one starts a project planning for it to fail. But the best indicator of a partner’s confidence in their own delivery is how they handle the exit scenario. A partner who is transparent about handover, code escrow, and documentation is a partner who expects to earn your business through quality — not through lock-in.

This is not a theoretical concern. Software companies cease trading, get acquired, or change strategic direction. If your partner disappears or decides to stop supporting your product, you need to be able to walk away without losing your investment. A contract that makes it difficult or expensive to leave is not a sign of a confident partner.

Key things to ask for:

• Code escrow: Is the source code placed in a third-party escrow account so you can access it if the partner ceases trading? Who pays for the escrow service?
• Documentation: What documentation will you receive? Architecture diagrams, API documentation, deployment scripts, environment configuration, runbooks for common operational tasks?
• Handover process: If you terminate the relationship, what does the transition period look like? Is there a defined handover period during which the partner supports the transfer of code, infrastructure, and knowledge to your team or a new partner?
• Source code access: Do you have access to the source repository from day one? Can you verify the code quality throughout the project, not just at the end?

Expected answer from a good partner: “You have access to the source repository from day one. On go-live, we transfer all code, infrastructure configuration, and documentation to you. We offer a 30–90 day handover period if you decide to transition to another partner. Code escrow is available at your cost.”

5. “What technologies do you use?”

Technology choices made early in a project determine your long-term maintainability. If a partner builds your ERP interface in an obscure framework, you will struggle to find developers to maintain it. If they use mainstream, well-supported technologies, you have a much wider talent pool to draw from.

This matters because software lives for years. The partner who builds it may not be the partner who maintains it. You need to be able to hire developers or engage a different agency to work on the codebase. If the technology is niche, your options narrow dramatically. The cost of maintaining a React application five years from now will be stable because the ecosystem is large and mature. The cost of maintaining an application built on a proprietary low-code platform will rise as the pool of available developers shrinks and the platform vendor dictates pricing.

The technology stack you should expect for a modern ERP interface layer:

• Frontend: React (with Next.js for server-side rendering and routing)
• Language: TypeScript (strict mode)
• Backend / API layer: Node.js or Next.js API routes
• Database (if needed): PostgreSQL or similar open-source relational database
• Hosting: AWS, Azure, or Google Cloud — Infrastructure as Code (Terraform, CDK)
• CI/CD: GitHub Actions or equivalent

Why this stack matters: React and TypeScript are the most widely used frontend technologies in the world. There are hundreds of thousands of developers familiar with them. If your partner ever ceases trading, you can find replacement developers easily. The stack is open-source, well-documented, and has a massive community. It is not going anywhere.

White flag: The partner uses proprietary low-code platforms, niche frameworks, or “their own” development platform. These create lock-in and reduce your options for future maintenance.

Expected answer from a good partner: “We build in React, Next.js, and TypeScript with PostgreSQL on AWS or Azure. All open-source, mainstream, and widely available. We do not use proprietary platforms or frameworks.”

6. “Can you show us a real example of your work?”

Any partner can describe their process. A good partner can show you real outcomes. Ask for case studies that include specific details: the client’s industry, the problem they solved, the technology used, the timeline, and the measurable results.

What to look for in a case study:

• Specific metrics: “Reduced order processing time from 4 minutes to 45 seconds” is meaningful. “Improved efficiency” is not.
• Honest scope description: What was included? What was explicitly out of scope?
• Third-party validation: Can you speak to the client? Will the partner arrange a reference call?

Questions to ask their references:

• Did the project come in on time and on budget?
• How did the partner handle unexpected issues?
• Would you work with them again?
• How responsive are they to support requests after go-live?
• Was the documentation adequate?
• How easy was the handover / transition?

Expected answer from a good partner: They provide two or three detailed case studies relevant to your industry, with named clients (permission allowing) and clear, quantified outcomes. They offer to arrange reference calls within a week.

7. “How do you handle scope changes?”

Scope changes are inevitable in any software project. The question is not whether they will happen, but how the partner manages them. The difference between a good partner and a bad one is transparency.

Some partners claim they “absorb” scope changes. This sounds generous, but it is actually a warning sign. No business can absorb unlimited changes without its margins being destroyed. The partner who says “we absorb it” is either not being honest about what constitutes a change, or is pricing so high that they have headroom to absorb changes — meaning you are overpaying upfront.

The honest approach: The partner defines a clear scope in the discovery document. Changes outside that scope are identified, documented, and priced separately. If the change is small (a few hours), they may absorb it as a gesture of goodwill. If it is significant, they raise a change request with a price and timeline impact, and you decide whether to proceed.

Expected answer from a good partner: “Scope is defined during discovery. Small changes we absorb. Significant changes go through a change request process: we document the change, the effort, and the cost, and you approve before we proceed. No surprises.”

8. “Do you subcontract work?”

Some software agencies operate as resellers: they win the contract, then subcontract the actual development to a third party — often offshore. You lose visibility into who is building your software, what their skill level is, and whether they are being paid fairly to stay motivated.

The subcontracting model is especially common among larger consultancies and digital agencies. They have a sales team that brings in work and a network of offshore development shops that do the delivery. The problem is that the sales team selling you the project may never have met the developers who will build it. The promises made during the sales process may not align with the delivery team’s capabilities or understanding of your requirements.

The problem with subcontracting: The agency has a margin between what they charge you and what they pay the subcontractor. That margin creates an incentive to minimise the subcontractor’s time — leading to rushed work. The agency also lacks direct control over quality, timelines, and communication. If the subcontractor has turnover, you may end up with a new, unfamiliar team mid-project.

The alternative: A dedicated, in-house team. The partner you hire is the team that builds your software. You know who they are. You can vet them. If someone leaves, you are told promptly and introduced to their replacement.

Expected answer from a good partner: “We do not subcontract. Our team is in-house and dedicated. You will know the names and faces of everyone working on your project. If we need specialist expertise for a particular component, we tell you in advance and you approve the arrangement.”

9. “What is your approach to security?”

An ERP interface layer connects to your core business systems. It handles sensitive data: customer records, financial information, pricing, and operational data. Security is not optional. You need specific, verifiable answers.

Security is not a feature you bolt on after the build is complete. It must be designed into the architecture from the start. A partner who talks about security only when you ask about it is less reassuring than one who raises the topic proactively in their proposal.

For UK businesses, there are specific standards and certifications that provide a useful baseline. Cyber Essentials is the UK Government’s minimum standard for cybersecurity. Cyber Essentials Plus adds independent verification. While not mandatory for most businesses, engaging a partner who has not bothered to achieve even the basic Cyber Essentials certification should give you pause.

Key security questions to ask:

• Hosting location: Where is the application hosted? UK-only data centres (Azure UK South or AWS London) are a baseline requirement for UK businesses handling personal data.
• Authentication: Does the application support SSO via Microsoft Entra ID (Azure AD)? Your team should not need a separate set of credentials.
• Data Processing Agreement (DPA): Will the partner sign a DPA that meets UK GDPR requirements?
• Cyber Essentials: Does the partner hold Cyber Essentials or Cyber Essentials Plus certification? This is a UK Government-backed certification that verifies basic security controls.
• Penetration testing: Can the partner provide recent penetration test reports? How often do they test?
• Field-level security: How is data access controlled at the application level? Customer portal users should see only their own data.
• Audit trail: Are all API calls and user actions logged for audit purposes?

Expected answer from a good partner: “We host exclusively in UK data centres. We support SSO via Microsoft Entra ID. We hold Cyber Essentials certification and conduct penetration testing annually. We will sign your DPA. Field-level security is built into our application architecture from day one. All actions are logged with a full audit trail.”

10. “What is your ongoing support model?”

Software is never finished. After go-live, you will need bug fixes, security patches, feature enhancements, and operational support. How the partner structures their support model tells you a lot about their long-term intentions.

Two common models:

Ad-hoc day rates: The partner charges you by the hour or day for support. This model gives them no incentive to be efficient — every support request is a revenue opportunity. It also makes budgeting unpredictable. You can never be sure what your support costs will be next month.

Monthly subscription: The partner charges a fixed monthly fee for hosting, maintenance, security patching, and a defined number of support hours. This aligns incentives: the partner wants to keep the application stable so they minimise support overhead. You get predictable budgeting and a dedicated point of contact.

A good subscription model typically includes hosting infrastructure, security patching and monitoring, bug fixes for defects in the original build, a defined number of hours for minor enhancements per month, and priority support with a defined SLA.

Expected answer from a good partner: “We offer a monthly subscription that covers hosting, security patching, monitoring, and a defined number of support hours. You get predictable costs and a dedicated support contact. Major new features are scoped and priced separately. There is a 12-month minimum term, then 30 days’ notice.”

---

Warning Signs: Red Flags in Proposals

Beyond the 10 questions above, watch for these warning signs in proposals and conversations:

Decision Framework: How to Score Potential Partners

Use the following table to evaluate each partner consistently. Score each criterion from 1 (poor) to 5 (excellent). A partner scoring below 35 should be eliminated from consideration.

Score each partner honestly. If a partner scores poorly on the Essential criteria, no amount of charm or competitive pricing should keep them in the race.

We recommend creating a weighted scorecard using this framework before you send out any proposal requests. Assign each partner a score for each criterion, multiply by the weight factor, and sum the total. This removes emotional bias from the decision and gives your procurement team a defensible, documentable rationale for the choice.

If a partner refuses to answer one of these questions, or gives an evasive answer, that is itself a data point. A trustworthy partner welcomes scrutiny. If they are defensive about their IP ownership terms or their subcontracting model before you have signed anything, imagine how difficult they will be to work with once you are under contract.

Frequently Asked Questions

How long does a typical custom ERP interface take to build?

After a discovery sprint, a focused build typically takes 4–12 weeks depending on scope. A staff operations dashboard might take 4–6 weeks. A customer-facing portal with full write-back capabilities might take 8–12 weeks. The partner should give you a specific timeline based on your specific scope.

What if we need to move faster than that?

Some partners offer an accelerated delivery model for well-defined, smaller-scope projects. This typically involves a tighter scope and a larger dedicated team. Ask your partner if they have an express track. If they say no without explanation, consider whether speed is a priority for them.

Can we start with a small project to evaluate the partner?

Absolutely. Many organisations prefer to start with a defined, small-scope pilot project — a single operational dashboard or a read-only customer portal — before committing to a larger programme. A good partner will accommodate this. A partner who insists on a large upfront commitment before delivering anything is a red flag.

How do we ensure knowledge transfer to our internal team?

Ask for a knowledge transfer plan as part of the build. This should include architecture walkthroughs, documentation review sessions, and hands-on access to the codebase from day one. Some partners offer a “shadowing” period where your developers work alongside theirs.

What happens if the partner goes out of business?

This is where code escrow, source code access, and comprehensive documentation become critical. If you have access to the source repository from day one, and if the code is well-documented and built on mainstream technologies, a new partner can pick it up with minimal friction. If the code is locked away in the partner’s proprietary infrastructure, you face a rebuild.

Should we include a service-level agreement (SLA) in the contract?

Yes. An SLA should cover availability (e.g. 99.5% uptime for the application), response times for critical and non-critical issues, and escalation procedures. A good partner will propose an SLA as part of their support model. If they resist including an SLA, or claim “we do not need one because we are responsive,” ask yourself how you would enforce responsiveness without contractual terms. Standard SLAs include: critical issue response within 4 hours during business hours, resolution target within 24 hours for critical issues, and regular status updates for ongoing investigations.

What is the difference between a partnership and a vendor relationship in software delivery?

A vendor relationship is transactional: you pay for a deliverable, they deliver it, and the interaction ends. A partnership is ongoing: the partner cares about your outcomes, not just your requirements. Signs of a partnership approach include proactive suggestions for improvement, transparency about challenges and risks, investment in understanding your business beyond the immediate project scope, and long-term commitment to the quality and maintainability of the code. You want a partner who will tell you when you are about to make a mistake, not one who will nod and invoice you for the consequences.

---