How to choose a development partner.

When people compare development agencies, they reach for the variables that are easy to see: the methodology, the portfolio, the size of the team, whether the deck says agile. These are weak predictors, and the reason they’re weak is that they describe how a team works rather than whether you’ll be able to tell, at the end, that the work was right. The thing that actually tracks outcomes is verifiability, and almost nobody screens for it, because it’s harder to see in a sales conversation than a logo wall.

Take the agile question, which comes up constantly: does agile actually work, or is it hype. The honest answer is that the question is miscast. Agile, waterfall, and every framework in between are scheduling decisions about when you find out things. None of them determines whether the software does what it should; they only determine how late you learn that it doesn’t. A team running flawless two-week sprints can ship a system nobody can verify, and a team with an unfashionable process can ship one that’s provably correct. The process is real, and it’s just not the variable doing the work. Asking whether agile works is like asking whether a calendar makes you punctual.

So when you’re choosing between agencies, the discriminating question isn’t about their process. It’s: what will you show me, during and after the build, that proves the system does what we agreed it would? A team built around that question has answers that sound concrete. They’ll describe the specs you’ll keep, the tests that have to pass before code reaches your repo, the transcript of the gates each change cleared. A team that isn’t built around it answers with reassurance, which is the tell. Reassurance is what you offer when you don’t have an artifact.

The redesign that killed the conversion rate

There’s a specific, painful version of this that we hear often enough to treat as a category: we redesigned our site, and our conversion rate fell off a cliff. The instinct is to blame the design, and sometimes the design is genuinely worse. But the more common story is structural, and it’s the same failure that haunts every kind of rebuild.

A redesign is a behavior change wearing a visual costume. The old page did a hundred small things that drove conversion, and almost none of them were written down as things. The form that pre-filled a field. The exact copy that survived a dozen rounds of testing. The order steps appeared in. The validation that fired before a user got frustrated rather than after. The redesign reproduced the look and quietly dropped a third of the behavior, because the behavior lived in the implementation and the brief described the appearance. Nobody decided to remove the thing that was working. It just wasn’t on the list, because no list of the actual behavior existed.

This is exactly the failure a behavior catalog is built to prevent. If the behavior of the page that converts is captured as a checkable inventory before the redesign, the redesign has a definition of done that includes the parts that made money, not just the parts you can see. And the new version can be held to it: the same behavioral checks that passed on the old page have to pass on the new one. That’s the same dual-green discipline we apply to a system rebuild, pointed at a funnel. A redesign shouldn’t be a coin flip on revenue, and the only reason it usually is comes down to the fact that the behavior at stake was never made explicit enough to protect.

What the right choice looks like

Choosing a partner well, then, isn’t about finding the team with the best-sounding process or the most relevant logos. It’s about finding the one whose answer to “how will I know this is right” is an artifact rather than an assurance. That filter is unglamorous and it’s also unusually reliable, because a team that can show you proof during the sale is a team that has proof to show, and a team that deflects to methodology is telling you, without meaning to, where the evidence isn’t.

I’d rather lose a comparison to a team that out-proofs us than win one on a better-sounding process. The first means the buyer learned to ask the right question. The second means they didn’t, and that’s the comparison nobody actually wins.