10 Questions to Ask Before Hiring a Custom CRM or ERP Developer

Most CRM and ERP projects don’t fail because the technology was wrong. They fail because the right questions weren’t asked before the contract was signed. I’ve been part of enough of these engagements — on both sides of the table — to know that the difference between a project that delivers and one that stalls is usually visible in the first conversation, if you know what to look for.

These are the ten questions I use. Not to disqualify vendors, but to understand how they actually work.

Before You Sign Anything, Ask These 10 Questions

Some of these will feel obvious. A few will make the vendor uncomfortable — and that reaction is worth noting. Both tell you something useful.

1. Who owns the code, the data model, and the integrations when the engagement ends?

This is the first question I ask — and the one that generates the most surprising answers.

The answer should be unambiguous: you own everything. If a vendor hesitates, qualifies ownership with licensing conditions, or references proprietary frameworks you can’t access without them, that’s a contractual dependency that will cost money later.

Specifically, ask about:

• Source code — full repository access, not just a deployment
• Database schema and data model — yours to migrate or extend
• API integrations — credentials, documentation, and configurations
• Deployment scripts and pipeline configuration — so another team can run and maintain the system

Ask for this in writing before the proposal stage. If the vendor treats it as an unusual request, that tells you something about their standard practice.

2. How do you handle scope changes mid-project?

Every CRM and ERP project changes after it starts. Business requirements shift. Stakeholders discover that what they asked for isn’t what they needed. Integrations turn out to be more complex than anyone estimated.

The question isn’t whether scope will change — it will. The question is what happens to the timeline and the budget when it does. Some vendors use change requests to renegotiate the entire engagement at premium rates. Others have a structured process for evaluating the impact of changes and absorbing reasonable variations within a defined framework.

Ask for a real example: a project where scope changed significantly and what happened to the timeline and cost. The specificity of that answer tells you more than any process document they’ll send you.

3. Can you show me a project that was harder than expected — and what you did about it?

Every vendor will give you their best case study. That’s not what you need.

The most revealing question in any vendor evaluation is about a project that didn’t go smoothly. Not a failure — a project that hit real obstacles: a data migration that took three times longer than planned, a third-party API that turned out to be undocumented, a client stakeholder who changed the requirements after sign-off.

How a team handles adversity under a live contract is a better predictor of outcomes than any successful reference they’ll volunteer. A vendor who can’t point to a difficult project and describe what they learned from it either hasn’t done enough work or isn’t being honest with you.

4. What does your process look like before you give us a price?

A vendor who quotes a price within 48 hours of a form submission is guessing. That number is based on assumptions about your data model, your integrations, your existing systems, and your team’s capacity to participate in the project — assumptions made without actually understanding any of it.

A vendor who does this well runs a structured discovery process before proposing anything — asking about your current workflows, your tech stack, your non-negotiable requirements, and the constraints that never make it into the initial brief.

When CodeBranch worked with an electrical network supply company on a custom ERP, the engagement ran through four steps before a line of code was written:

1. Technology selection — evaluating what stack fits the actual requirements
2. Solution design — architecture decisions made before implementation begins
3. Delivery planning — milestones, scope, and acceptance criteria defined upfront
4. Task assignment — who does what, with what standard

That structure made it possible to launch with initial production capabilities in the second month. See the ERP case study for the full details.

A vendor who skips this step will cost you more than their lower initial quote suggests.

5. How do you handle data migration from legacy systems?

This is where most CRM and ERP projects get their first real surprise.

Every company that needs a custom CRM or ERP already has data somewhere — spreadsheets, an old system they’ve outgrown, a mix of both. Moving that data into a new platform is rarely as straightforward as it sounds. Field mappings don’t match, data quality turns out to be inconsistent, and the business keeps operating while the migration is happening.

A vendor who gives you a confident one-line answer to this question hasn’t done enough migrations. The right answer describes a process: data audit before migration begins, a staging environment where data integrity is validated before anything goes live, and a rollback plan if something breaks. Ask specifically about how they handle records that don’t map cleanly — the edge cases are where migrations fail.

Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals — and data migration is consistently cited as one of the primary contributors to that failure rate. It’s not a technical footnote. It’s a project risk that needs a plan before kickoff, not during.

6. Who will actually work on my project — and will that team stay consistent?

The team presented during the sales process is often not the one that shows up after signing. Senior engineers build confidence in early conversations; junior developers handle the actual work. On a CRM or ERP project — where the system needs to model specific business workflows — team continuity matters more than in most other types of development.

Ask directly: who are the specific people who will work on this project? What is their seniority? What happens if one of them leaves during the engagement? Is there a process for knowledge transfer if the team changes?

7. What does your QA process look like — and at what stage does it happen?

If the answer is “we test at the end,” that’s a structural problem.

Quality assurance that happens only after development is complete catches defects late — when fixing them costs the most. On a CRM or ERP project, where business logic is complex and a data error in production has real consequences, late-stage QA is a structural risk.

Quality checks should be embedded throughout the cycle, not added at the end:

• Automated tests on every commit — not run manually before a release
• Code reviews at the pull request level — before code reaches the main branch
• QA involvement from requirements — not introduced at the end to verify what developers already built

Ask the vendor to describe what happens between a developer finishing a feature and that feature reaching production. Every step they can’t name is a gap.

When QA is embedded this way — using automated agents to audit code and run testing loops in real time — the results are measurable. In a recent CodeBranch healthcare project, this exact workflow produced an 85% reduction in QA rejection rates. The pipeline caught defects before they reached human review, which freed the QA analyst to focus on the edge cases that actually require judgment.

8. How do you incorporate AI into your development process — and what does that mean for delivery speed?

This question separates vendors who have thought seriously about AI from those who mention it in their deck without changing how they actually work.

The relevant question is not whether they use AI tools — most development teams do at this point. The relevant question is whether AI is integrated into the pipeline in a way that produces measurable differences in delivery speed and output quality, or whether it’s used ad hoc by individual developers with no shared standards.

A vendor running an agentic development pipeline — where AI agents operate within a structured CI/CD workflow, with quality gates that catch AI-specific failure patterns before human review — will deliver differently than a vendor where a developer occasionally uses a code assistant. The Stack Overflow 2025 Developer Survey found that 66% of developers cite AI solutions that are “almost right, but not quite” as their biggest frustration. Tools operating without a structured pipeline around them produce that result consistently.

For a CRM or ERP project, where the delivery timeline directly affects when the business can operate on the new system, this question has a real financial answer. Ask for a concrete example: a recent project where their AI process changed what they could deliver, and by how much.

9. What happens if the project takes longer or costs more than projected?

This question makes some vendors uncomfortable — and that reaction is worth noting.

Cost overruns and timeline slippage are common enough in CRM and ERP projects that the question isn’t whether they might happen — it’s who absorbs the impact when they do. Some vendors build contracts that transfer most of that risk to the client through open-ended time-and-materials billing. Others offer fixed-price engagements with clearly defined scope, where the vendor is accountable for delivering what was agreed without recharging for their own estimation errors.

Ask the vendor directly: if the project runs 20% over the original timeline, what happens to the budget? If the answer involves billable hours for work that should have been in the original scope, that’s a pricing model question disguised as a project risk question.

The vendors who perform well on this are the ones who invest in thorough discovery before pricing — not the ones who offer the lowest initial quote.

10. What does the handoff look like at the end of the engagement — and what will I be able to do independently when it’s over?

This question reveals whether a vendor builds independence or dependency.

A vendor who delivers a working system but leaves the client unable to maintain, extend, or understand it has created a different kind of lock-in — not contractual, but practical. The client ends up back at the same vendor for every change, every bug, every new feature, because nobody else can navigate what was built.

Ask specifically:

• What documentation is delivered at the end of the engagement?
• Is the codebase structured so another team could pick it up?
• What training or knowledge transfer is included?
• Is there a runbook for operating and maintaining the system?

A vendor who answers these questions clearly — with specifics about deliverables, documentation standards, and what the client’s team will be able to do independently — is a vendor whose interest is aligned with yours after the contract ends, not just during it.

What the Answers Tell You

No single question in this list is definitive on its own. What you’re looking for is a pattern.

A vendor who has clear answers on IP ownership, a structured pre-engagement process, embedded quality checks, and honest documentation of what you’ll have at the end — is a vendor who has built their practice around delivering projects, not just winning them.

The inverse is also true. Vague answers about ownership, a price that arrived before any real discovery, QA described as a final phase, and no clear answer about what the handoff looks like — each of those individually might be explainable. Together they describe a vendor whose process is optimized for signing contracts, not completing them.

CodeBranch is an agentic software development boutique based in Medellín, Colombia, specializing in AI-optimized development pipelines for product teams in the United States. We’ve run these questions on ourselves — because the same standard that makes a vendor worth hiring is the standard we’d want applied to us. Our pre-engagement process is documented and public. If you’re evaluating a CRM or ERP development partner and want to put these questions to work, start there.

Written by Jorge A. Mora, Co-founder at CodeBranch — Medellín, Colombia.