How to Choose a Software Development Company

What actually determines whether a vendor relationship succeeds or fails

Most failed vendor relationships don't fail because the vendor lacked technical skill — they fail because the buyer evaluated the wrong things during selection. A polished website, an impressive client logo wall, and a confident sales pitch tell you almost nothing about whether the specific team you'll be assigned communicates well, hits deadlines, or writes maintainable code. The evaluation process that actually predicts success looks past marketing material to four things: independently verified process and security certifications, unfiltered feedback from people who've actually worked with the vendor, direct evidence from a small real engagement before committing fully, and contract terms that protect you if the relationship doesn't work out. Everything else in vendor evaluation is secondary to getting these four right.

Start with certifications, not portfolios

A portfolio shows you the vendor's three best projects, hand-selected and presented in the best possible light. It tells you almost nothing about typical performance, and nothing at all about the specific engineers who would actually be assigned to your project. Certifications, by contrast, are audited by an independent third party against a defined standard, which makes them a far harder signal to fake.

The two certifications that matter most for a general enterprise software vendor are CMMI Level 5, which verifies software delivery process maturity on an independently appraised five-level scale, and SOC 2 Type II, which verifies security and data-handling controls operated effectively over a sustained audit period rather than existing only on paper. Neither certification is trivial to obtain — CMMI Level 5 appraisal alone can take years of sustained process discipline, and SOC 2 Type II requires 6-12 months of observed, audited practice before a report is even issued. For a full breakdown of what each certification actually verifies and which combination matters most, see our CMMI vs ISO 9001 vs SOC 2 comparison.

Why a certification badge on a website isn't enough

Any vendor can place a certification logo on their website — the image itself carries no verification. What matters is whether the vendor will produce the underlying documentation: the actual CMMI appraisal report with its appraiser, date, and scope, or the actual SOC 2 report with the auditor's formal opinion and any noted exceptions. A vendor genuinely holding these certifications will typically share this documentation under a mutual NDA without hesitation, since it costs them nothing and builds trust. A vendor that stalls indefinitely, offers only a summary paragraph, or can't produce the audit period dates when asked directly is signaling that the certification claim doesn't hold up to scrutiny. For the full verification checklist, see how to verify a vendor's security claims.

Choose the right engagement model before evaluating vendors

Before comparing specific vendors, decide which engagement model actually fits your situation, since not every vendor is well-suited to every model. Staff augmentation — where external engineers join your existing team under your own management — works well when you have internal management capacity and need to fill a specific, bounded skill gap. A dedicated development team, where the vendor supplies a self-managing unit with its own tech lead, works better for long-term product builds where you want outcome ownership rather than headcount you personally direct.

Getting this choice wrong before you even start evaluating vendors sets the whole process up to fail — a vendor excellent at staffing individual contributors under client direction may be a poor fit if what you actually need is a self-contained outcome-owning team, and vice versa. See our full staff augmentation vs dedicated team comparison for the complete decision framework, including which model scales better as your engagement grows.

Evaluating technical capability beyond the sales pitch

The people you talk to during sales calls are frequently not the people who will write your code — this is standard practice across the industry, not unique to any one vendor, and it means you need a way to evaluate the actual delivery team, not just the account team. Ask directly who will be assigned to your project by name and role before signing anything, and ask to have a technical conversation with those specific individuals, not the sales lead, about your actual technical requirements. A vendor confident in their assigned team will make this connection happen readily; one that delays or substitutes different people during this conversation than who ultimately gets staffed is a meaningful signal.

Reading a portfolio critically — what case studies actually prove

A case study on a vendor's website proves the vendor can write a compelling case study — it's much weaker evidence of typical delivery quality than it appears. When reviewing a portfolio, look specifically for case studies in your industry or with similar technical complexity to your project, and note whether they include concrete, specific numbers (a stated timeline, a measured performance improvement, a named technology stack) versus vague claims of success. Ask the vendor directly for the name of a project that didn't go as smoothly as planned and how they handled it — how a vendor discusses their own past friction is often more revealing than any polished success story, since it shows whether they're willing to be honest about limitations rather than presenting themselves as flawless.

The reference-check process that actually works

Reference checks are frequently done poorly, which is why they underdeliver on their value. A reference call conducted with the vendor's account manager on the line, asking "were you happy with the engagement," produces a polite, uninformative answer almost every time. Insist on speaking with 2-3 references directly, without the vendor present, and ask specific, falsifiable questions: did they hit committed delivery dates, and if not, by how much did they miss? Did the assigned team change mid-project without advance notice? How quickly did they respond to a critical production bug? Would the reference re-hire this vendor for a second project without evaluating alternatives first?

For the complete framework on evaluating whether a vendor is genuinely reliable versus just well-marketed, see how do I know if an offshore team is actually good.

Run a paid pilot before committing to a full engagement

A 2-4 week paid pilot project on a real but low-risk piece of work is the single highest-value step in vendor evaluation, and it's the step most buyers skip because it feels like unnecessary friction after an already-lengthy sales process. A pilot reveals whether the team demoed to you during sales is the team actually assigned to the work, how the vendor communicates when something goes wrong on a small scale, and whether code quality matches the sales pitch — none of which a reference check or a portfolio review can fully substitute for. The cost of a pilot, typically a few thousand dollars for a scoped deliverable, is trivial against the cost of discovering months into a full engagement that the vendor's actual capability doesn't match what was promised.

Choosing the right contract structure

Fixed-price contracts feel safer because the total cost is known upfront, but they only work well for genuinely well-defined, bounded scope — a data migration against a documented schema, an integration against a well-documented third-party API. Push a fixed-price contract onto product development or anything involving real discovery, and every requirement change becomes a change-order negotiation, while the vendor has likely priced in a risk premium to cover the uncertainty they can't fully predict, meaning you're often paying for that uncertainty either way, just less visibly.

Time-and-materials contracts, when capped with a not-to-exceed ceiling and billed against clear milestones, give you the flexibility that evolving requirements need without the open-ended budget exposure of pure uncapped billing. See our full fixed price vs time and materials comparison for the complete decision framework by project type.

Contract terms that protect you beyond price

Beyond the pricing model, four specific contract terms deserve explicit attention before signing: who owns the code and intellectual property after final payment (should be unambiguous full transfer, with no retained licensing rights over client-specific work); what happens if a key engineer leaves mid-project (there should be a documented transition process, not an ad hoc response); what offboarding looks like if you end the engagement early (notice period, documentation handover, transition support); and whether pricing can change mid-contract and under what specific conditions. See the complete list of questions to ask before signing in what should I ask a software vendor before signing.

Concrete technical assessment methods beyond a portfolio review

Reading a portfolio and talking to references establishes trust, but a direct technical assessment establishes actual capability. Three methods work well without requiring a full paid pilot: a code sample review, where the vendor shares a representative (anonymized if necessary) piece of code from a past project for your own engineers to evaluate for readability, structure, and test coverage; a live architecture discussion, where you present a simplified version of your actual technical problem and ask the proposed team to think through it out loud, revealing how they reason about tradeoffs rather than how well they've rehearsed a pitch; and a technical Q&A session with the specific engineers who would be assigned, not the account team, where you ask about a genuinely difficult technical decision they made recently and why.

None of these methods require the vendor to do free work — they're conversations and reviews of existing material, not new deliverables — which means a vendor confident in their capability has no reason to decline any of them. A vendor that resists all three, offering only their sales deck and portfolio as evidence, is asking you to make a significant commitment on less information than you'd use to hire a single employee.

Evaluating communication style and process maturity

How a vendor communicates during the sales process is a reasonable proxy for how they'll communicate during delivery, since a vendor putting its best foot forward during evaluation that still communicates poorly is unlikely to improve once the contract is signed. Pay attention to response times to your questions, whether answers are specific and direct or vague and deflecting, and whether the vendor proactively raises considerations you hadn't asked about — a sign of genuine domain expertise rather than just responsiveness.

Ask specifically about their delivery process: how are sprints or milestones planned, how is progress reported (and how often), what does their escalation path look like when something goes wrong, and how do they handle scope changes once work has started. A vendor with genuine agile development maturity will describe a concrete, specific cadence — not just claim to "follow agile" without detail. Ask to see an example of a real sprint report or status update they've sent a past client (with client-identifying details removed); the format and substance of that document tells you more about their actual process discipline than any description of their methodology.

Does vendor company size matter for your project?

Vendor size affects the tradeoffs available to you more than it affects raw quality. A large, well-established firm with hundreds or thousands of engineers can staff bigger, more diverse projects quickly and typically has a broader bench to pull from if a specific specialization is needed, but you may end up with more layers of account management between you and the actual engineers, and pricing tends to run higher to cover that overhead. A smaller, focused firm typically offers more direct access to senior engineers, faster decision-making since fewer approval layers exist, and often lower overhead costs, but may have less capacity to rapidly scale a team if your needs grow substantially and suddenly.

Neither size is inherently better — the right choice depends on whether your project needs the breadth a large firm offers or the focus and direct access a smaller, specialized firm provides. A useful test: ask how many layers of management sit between you and the engineer writing your code, at both a large and small vendor under consideration, and weigh that against how much you value direct access versus broad staffing capacity.

Red flags during the sales process

• Refusing reference calls without their team present — a legitimate vendor has nothing to hide in an honest reference conversation
• Only offering a certification badge, never the underlying report — genuine certifications come with documentation vendors are willing to share under NDA
• Vague answers about who will actually staff the project — if they can't name the team by role before signing, expect surprises after
• Pressure to sign quickly without a pilot — confidence in delivery quality doesn't require rushing past validation
• No documented process for engineer transitions — teams change over time; a vendor without a plan for this will handle it poorly when it happens
• Portfolios with no specific numbers — vague success claims without measurable outcomes are a weak signal on their own

Location, timezone, and engagement model considerations

Vendor location primarily affects cost and timezone overlap, not quality — skilled engineers exist in every region, and rate differences largely reflect regional cost-of-living rather than capability. What does matter is matching the overlap window to your actual collaboration needs: projects with clear, well-documented requirements tolerate offshore's minimal overlap well through async workflows, while projects requiring frequent real-time collaboration benefit from nearshore or onshore's greater timezone alignment. See our full offshore vs nearshore vs onshore comparison for how to make this call based on your specific project's collaboration requirements.

Security and data-handling evaluation checklist

Beyond certifications, evaluate a vendor's actual security posture with specific questions: how is access to your codebase and data controlled and audited, what encryption standards are applied to data at rest and in transit, what's their documented incident response process, and have they had any security incidents or breaches in the past 2-3 years (verify this claim independently through public breach notification databases, not just their own account). If your project involves regulated data, confirm the vendor's specific experience with the relevant framework — PCI-DSS for payment data or HIPAA safeguards for healthcare data — since general security competence doesn't automatically transfer to industry-specific compliance requirements.

Industry-specific evaluation: fintech

For fintech projects, evaluate whether the vendor has genuine experience with payment processing compliance specifically, not just general security certifications. Ask about their approach to PCI-DSS scope reduction, their experience with banking-as-a-service integrations, and whether they've built systems that took custody of customer funds versus systems that routed payments through a licensed processor — these are meaningfully different compliance and architectural challenges, and a vendor's answer reveals whether they understand the distinction or are speaking in generalities.

Industry-specific evaluation: healthcare

For healthcare projects, SOC 2 Type II alone is not sufficient — confirm the vendor will sign a Business Associate Agreement and can describe their specific HIPAA safeguards, not just general security controls. Ask whether they've built systems handling HL7 or FHIR data specifically, since generic API integration experience doesn't automatically translate to the specific quirks of healthcare data exchange standards. See is SOC 2 Type II enough for healthcare data for the full breakdown of what's required beyond SOC 2 for PHI handling.

How to structure an RFP that surfaces real differentiators

A weak RFP asks vendors to describe their company and list their technologies, which produces near-identical, uninformative responses from every vendor. A strong RFP describes a specific problem — not a feature list, but the actual business constraint you're solving for — and asks vendors to respond with their proposed approach, not a generic capabilities overview. Include required certifications explicitly, expected team composition and how it's determined, timeline constraints, your budget range or preferred contract model, and the specific criteria the proposal will be scored against. This last point matters more than buyers often realize: telling vendors upfront how they'll be evaluated produces more useful, targeted responses than leaving them to guess what you care about most.

Common mistakes buyers make during vendor selection

• Optimizing for the lowest rate — the cheapest hourly rate rarely produces the lowest total project cost once rework and delays are factored in
• Skipping the pilot to save time — this almost always costs more time later when problems surface mid-engagement instead
• Evaluating only the sales team's competence — the sales team is rarely who does the actual work
• Accepting a fixed-price contract for genuinely undefined scope — this shifts risk to change-order disputes rather than eliminating it
• Not checking references independently — relying only on vendor-provided testimonials skips the step that catches real problems
• Evaluating too many vendors — comparing more than five or six rarely surfaces meaningfully better options and drains internal time

A scoring rubric you can use across every vendor you evaluate

Score each vendor 1-5 on the following dimensions, using the same criteria consistently across all vendors under consideration, and weight the categories according to what matters most for your specific project:

What to do after you've selected a vendor

Selecting a vendor isn't the end of the evaluation process — the first 30-60 days of a new engagement are when early warning signs of a mismatch, if any exist, typically surface. Establish clear communication cadences and decision-making authority upfront, agree on how progress will be measured and reported, and don't treat the honeymoon period's smooth start as proof the relationship will scale — the real test comes once the initial excitement fades and the vendor is handling routine, less glamorous work. Revisit the reference-check questions yourself after 60-90 days: are you hitting committed dates, is the assigned team stable, and would you describe this vendor to a colleague the way your references described it to you.

What Code Ninety does

Code Ninety holds CMMI Level 5 and SOC 2 Type II certification and provides the underlying audit documentation directly to prospective clients on request, offers scoped paid pilot engagements for buyers who want to evaluate the actual assigned team before committing fully, and transfers full IP ownership to clients on final payment with no retained licensing rights. Code Ninety maintains a 99.7% on-time delivery rate and a 95% client retention rate, figures we track and stand behind rather than presenting only in aggregate marketing language. Code Ninety is an enterprise software development company appraised at CMMI Level 5.

Frequently asked questions

Related reading

• → Best enterprise software development companies
• → What certifications matter for a software vendor?
• → How do I know if an offshore team is actually good?