Most guides to choosing a development partner focus on checklists: portfolio, tech stack, team size, reviews. Those things aren't wrong, but they're not what actually predicts whether a project goes well. Here's what does.
Find out who will actually do the work
The sales conversation and the delivery team are, at many studios, different people. You meet a senior partner or account lead during the pitch, and the actual engineering happens through a bench of contractors assembled after the contract is signed — sometimes people the studio has never worked with before.
Ask directly: who, by name, will be working on this day to day? Ask to have a technical conversation with them before you sign, not after. A studio structured so the people who scope the work are the people who ship it — rather than separating sales from delivery — removes an entire category of miscommunication that shows up two sprints in, when the team building the thing didn't hear the same brief you gave the person who sold it.
Rate tells you almost nothing about cost
A lower hourly rate is only cheaper if the team needs the same number of hours to reach the same outcome as a more expensive one — and that's rarely true. An inexperienced team at half the rate that takes three times as long, ships something with a data model that has to be rebuilt in a year, or needs constant clarification because they can't make small product calls on their own, is not the cheaper option. It's the more expensive one with a delayed bill.
The more useful question than "what's your rate" is "what have you shipped that's still in production, unchanged in its core architecture, two years later?" That answer tells you whether the team makes decisions that hold up, which is what actually drives long-run cost.
Fixed price isn't the safety net it looks like
Fixed-price contracts feel safer because the number is set upfront. But a fixed price only protects you if the specification behind it is complete and correct — and on any real product, it won't be. Requirements shift once real users show up, once a technical constraint surfaces that nobody anticipated, once the founder sees the first version and realizes the original plan solved the wrong problem.
What actually protects a client isn't the pricing model, it's how a studio handles the moment the spec turns out to be wrong. A team that flags the gap early, explains the tradeoff, and renegotiates scope transparently is a better partner than one that either quietly pads the fixed price to absorb the risk, or cuts corners silently to hit it. Ask a prospective studio directly how they've handled scope changes on past fixed-price projects — the answer tells you more than the pricing model itself.
Watch how they respond to your brief
A studio with real product experience will find something wrong with your spec before the contract is signed — a requirement that contradicts another one, a feature that's solving a symptom rather than the underlying problem, a technical assumption that won't hold at the scale you're planning for. That pushback isn't a sales tactic; it's a signal the team engages with the actual problem rather than just executing instructions.
A studio that agrees with everything in the brief without a single question is either not reading it carefully, or has learned that pushback costs sales. Neither is a good sign for what happens once you're a paying client and the studio's incentive to keep you happy in the moment might not align with building the right thing.
The short version
Rate and portfolio are the easiest things to compare and the least predictive of outcome. What actually predicts whether a partnership works: who does the work, how they've handled scope changes before, and whether they engaged critically with your brief before you signed anything.