Choosing a Partner · the honest version

How to Evaluate a
Software Development Partner.

The portfolio is the easy part. Here's what to look for - beyond the sales deck - before you sign anything.

Talk to our team

// choosing a partner

The portfolio is the easy part.

Picking a software development partner is one of the highest-stakes decisions a technology leader makes. A good partner accelerates everything. A bad one costs you a year, a budget, and - if you're unlucky - your job.

The challenge is that most firms look roughly the same at the surface level: polished website, strong portfolio, confident sales team, competitive proposal. The differences only become visible after you've signed.

Here's what to look at before you get there.

Less Portfolio.
More Proof.

Pressure-Test Your Shortlist

// reframe the evaluation

Evaluate how they behave when it's hard.

Most organizations evaluate partners on past work, proposed approach, price, and references. Those matter - but they're also easy to manage.

Portfolios show best-case work. Proposals are optimistic. Prices are negotiated. References are curated. What you actually want to know: how does this team behave when things get hard?

Because things will get hard - requirements change, technical constraints emerge, timelines shift. A partner who performs well in smooth conditions and falls apart under pressure is a partner who will fail you at exactly the wrong moment.

// the checklist

10 things to actually evaluate.

  • 01

    How do they handle the first hard question you ask?

    Green flag Honest engagement with the difficulty: "This is hard because X. Here's how we'd approach it."
    Red flag Instant accommodation - "Sure, we can do that" with no discussion.
  • 02

    Can they explain technical decisions in plain language?

    Green flag A clear explanation with the tradeoffs acknowledged.
    Red flag Jargon deflection. Complexity used as a smokescreen.
  • 03

    What has gone wrong with past projects?

    Green flag A specific example - what went wrong, and what they changed.
    Red flag "We've never had a project go sideways." Untrue - and a tell that they won't be honest with you.
  • 04

    Who will actually work on your project?

    Green flag Named team members with real backgrounds and a clear ownership structure.
    Red flag Vague answers about "our team"; promised resources that aren't specific people.
  • 05

    How do they handle scope changes?

    Green flag A clear, fair change-order process - documented and priced transparently, no surprises.
    Red flag Either extreme: "we'll figure it out," or nickel-and-diming every conversation.
  • 06

    What does the code look like?

    Green flag Code clearly written to be maintained by humans, with tests.
    Red flag Code that only works if the original author is there to explain it.
  • 07

    How do they communicate bad news?

    Green flag Early, and with options - not just problems.
    Red flag You found out from someone else. They minimized it, or got defensive.
  • 08

    Do they push back on bad ideas?

    Green flag During the sales process, they've already pushed back on something.
    Red flag Total agreement with everything you've said. Pure accommodation is not a feature.
  • 09

    What happens at the end of the engagement?

    Green flag Clear knowledge transfer, the code is yours, and the exit is considered up front.
    Red flag Vague answers. "We'll handle it." Reluctance to discuss the exit at all.
  • 10

    Does the contract reflect the conversation?

    Green flag A contract that reflects a mutual relationship with reasonable protections on both sides.
    Red flag A fortress of liability protection designed to shield the firm from any accountability.

// proposal red flags

Red flags in the proposal process.

Some signals show up before you've even chosen - in how the proposal itself arrives.

  • Proposals that arrive immediately, fully formed, without discovery.
  • Scope so detailed it assumes they already know what you need.
  • Timelines that seem impossibly short - or impossibly long.
  • No questions about your existing systems, team, or organizational constraints.
  • A price that is dramatically lower than every other bid.
Discovery. Scope. References. Contract. ·  Discovery. Scope. References. Contract. · 

// a good process

What a good evaluation process looks like.

01

Start with requirements

Understand what you actually need before you invite vendors to propose - not the other way around.

02

Limit your shortlist

Evaluating ten vendors produces anxiety, not insight. Three is better.

03

Run a paid discovery

The best way to evaluate a partner is to work with them on something small and real.

04

Call the references they didn't give you

Find clients outside the provided list. Platforms like Clutch have reviews that aren't curated.

05

Trust your read on the people

Technical evaluation matters. So does whether you trust the people you'd be working with.

// how we handle it

How Inventive handles this conversation.

We're comfortable with this kind of scrutiny. We'd rather you ask the hard questions in evaluation than find out the answers the expensive way.

If you're comparing vendors, we'll tell you what questions to ask the others. If we're not the right fit for your situation, we'll tell you that too.

ready when you are

Put us through the wringer.

Ask us the hard questions - we'll give you straight answers, and tell you what to ask the other firms too. If we're not the right fit, we'll say so. We reply within one business day.

Schedule a conversation Or see our work