TL;DR
A structured due-diligence framework for evaluating custom software vendors: IP ownership, milestone controls, technical discovery, and exit clauses.
How to Evaluate a Custom Software Vendor Before Signing the Contract
Your operations director has just flagged a problem: the customer portal your team commissioned eight months ago is six weeks behind schedule, the vendor is requesting a 30% budget increase, and your legal team has discovered that the source code technically belongs to the development firm until final payment clears. The contract you signed in week one said nothing meaningful about milestone gates, code escrow, or termination rights.
This situation is more common than most executives admit. Custom software development is one of the highest-stakes procurement decisions a mid-market company can make, and the evaluation phase — not the development phase — is where most projects are won or lost. This article gives you a structured due-diligence framework to apply before any contract is signed.
Why Standard Vendor Vetting Falls Short
Most procurement teams evaluate software vendors the way they evaluate office supplies: price, references, and turnaround time. For custom software, that approach ignores the variables that actually drive project success.
Custom development involves a long-term, interdependent relationship. You are not buying a finished product. You are buying a team's capacity to make good decisions under uncertainty — about your requirements, your infrastructure, your users, and your budget. The evaluation process must reflect that reality.
The Four Pillars of Vendor Due Diligence
1. Intellectual Property Ownership
Before any technical conversation begins, clarify IP ownership in writing. The default in many jurisdictions is that a contractor retains copyright unless the contract explicitly assigns it to the client. Ask for the following in plain language:
- Who owns the source code at each stage of development?
- Are there any third-party libraries, frameworks, or proprietary modules that cannot be transferred?
- What happens to IP ownership if the contract is terminated mid-project?
A vendor unwilling to assign full IP to the client at contract signing — or at minimum at each paid milestone — is a vendor whose incentives are not aligned with yours.
2. Milestone Controls and Payment Structure
Avoid contracts that front-load payment or tie the final large payment to vague "project completion" language. A well-structured milestone plan gives you leverage and reduces your financial exposure.
| Payment Structure | Risk Level | Vendor Incentive Alignment |
|---|---|---|
| 50% upfront, 50% at completion | High | Low — vendor has cash before delivery |
| Equal monthly retainer, no milestones | High | Low — no accountability to outcomes |
| Milestone-based with defined deliverables | Medium | High — payment tied to demonstrable progress |
| Milestone-based with client acceptance criteria | Low | High — vendor must meet your definition of done |
| Escrow-held releases tied to QA sign-off | Low | Highest — third-party verification required |
Insist on written acceptance criteria for each milestone. "Working login functionality" is not an acceptance criterion. "Users can authenticate via email/password and OAuth 2.0 with a session timeout of 30 minutes, verified in staging" is.
3. Technical Discovery Quality
A vendor's approach to the discovery phase reveals more about their capability than any portfolio presentation. Discovery should result in a documented technical specification that includes architecture decisions, data flow diagrams, third-party integration dependencies, and a realistic risk register.
Watch for vendors who rush discovery to reach the billing phase faster. A thorough discovery process typically takes two to four weeks for a mid-complexity project and should produce artifacts your internal team — or an independent reviewer — can evaluate critically.
Ask directly: "What risks have you identified in our requirements that we haven't discussed yet?" A strong vendor will name specific technical constraints, integration challenges, or scope ambiguities. A weak vendor will give you a blank look or a sales answer.
4. Exit Clauses and Transition Rights
Every contract should define what happens when the relationship ends — whether by choice or by failure. Evaluate the following before signing:
Vendor Due Diligence Checklist
- Source code delivered to client-controlled repository at each milestone
- Documentation standards defined and enforceable
- Transition assistance clause (minimum 30–60 days of handover support)
- No vendor lock-in to proprietary tooling without client consent
- Data export rights in a portable, documented format
- Non-compete or exclusivity terms reviewed by legal counsel
- Dispute resolution mechanism specified (arbitration, jurisdiction, escalation path)
- Liability caps reviewed relative to contract value and business risk
How a Technology Partner Should Approach This Problem
A genuine technology partner — as opposed to a transactional vendor — will not resist structured due diligence. In fact, they will often initiate it.
Before signing, a strong partner should be asking you questions you haven't considered: What does success look like in 18 months? Who internally owns the relationship after launch? What is your tolerance for scope changes once development is underway? Do you have the internal capacity to provide timely feedback during sprint reviews?
The partner's pre-contract behavior is a leading indicator of their behavior under pressure. If a vendor is evasive about their subcontracting practices, slow to provide references, or resistant to code escrow arrangements, those patterns will amplify when the project hits its first major obstacle.
Ask to speak with the specific developers and architects who will work on your account — not just the sales team. Evaluate their communication style, their ability to explain technical constraints in business terms, and their willingness to push back on impractical requirements.
Common Implementation Mistakes and Mitigations
Mistake: Accepting a fixed-price contract for a poorly defined scope A fixed price without a locked scope is not a fixed price. It is a conflict waiting to happen. Mitigation: complete a paid discovery phase before committing to a development budget.
Mistake: Delegating vendor oversight entirely to a single internal champion If that person leaves or is reassigned, institutional knowledge disappears and vendor accountability evaporates. Mitigation: require written status reports on a defined cadence and maintain executive-level touchpoints at each milestone.
Mistake: Treating the contract as a one-time event Contracts need to be reviewed when scope changes, team composition changes, or timeline changes. Mitigation: build a formal change-order process into the original agreement, with defined approval thresholds.
Mistake: Skipping independent technical review Vendors grade their own work. Mitigation: budget for an independent code review at each major milestone, conducted by a party with no financial relationship to the development vendor.
Mistake: Neglecting security and compliance requirements until late in development Retrofitting security controls is expensive. Mitigation: define your compliance requirements — whether GDPR, HIPAA, SOC 2, or internal data governance policies — in the contract's technical requirements section, not as an afterthought.
What to Measure in the First 90 Days
Once development begins, these KPIs give you an objective basis for evaluating whether the engagement is on track.
| KPI | Target | Red Flag |
|---|---|---|
| Sprint velocity stability | Within ±15% of baseline after sprint 3 | Declining velocity after week 4 |
| Milestone acceptance rate | ≥90% of deliverables accepted on first review | Repeated rework cycles on same features |
| Bug escape rate (staging to production) | <5% of test cases result in production defects | High defect volume after UAT sign-off |
| Requirement change requests | Tracked and tiered by impact | Untracked scope creep absorbed without documentation |
| Communication response time | Critical issues acknowledged within 4 business hours | Consistent delays exceeding 24 hours |
| Documentation completion | 100% of delivered features documented at milestone | Documentation deferred to "end of project" |
Review these metrics formally at the 30-day, 60-day, and 90-day marks. If two or more KPIs are consistently in red-flag territory by day 60, treat it as a structural problem — not a temporary delay.
Making the Decision
Vendor evaluation is a discipline, not a checkbox. The firms that navigate custom software projects successfully invest as much rigor in the selection process as they do in the development itself. They ask uncomfortable questions before contracts are signed, structure payments to maintain leverage, and define success in measurable terms before a single line of code is written.
The goal is not to find a vendor who agrees to everything. The goal is to find a partner whose incentives, processes, and capabilities align with your business outcomes — and to confirm that alignment in writing.
Talk to Valego: info@valegos.com