What to ask before trusting someone with your product build

“How do I know if I can trust whoever I hire to build this?” It's the right question, and most founders ask it too late. Here's the uncomfortable math: a bad build costs you twice. You pay for the build, and then you pay again for the redo — usually after months of lost time and a product that never quite worked. The second bill is always bigger than the first.

The trap is thinking you can avoid this by inspecting the work. You can't evaluate the code — most founders can't, and that's fine; you shouldn't have to. So you're left evaluating the people. After 22 years in startups across healthcare, security and privacy, the gig economy, and commercial contracts, I can tell you every industry comes down to the same thing: understanding the people and their needs, not just the technology. The code we provide is merely an artifact. What you're interfacing with is not the contract; it's the people behind it.

You're not trusting the code I write — you're trusting me to write the correct code.

Here's where I'd reverse the usual advice. Everyone tells you to arm yourself with a checklist of questions to grill your developer or agency with. That's not wrong, but it misses the real signal: whether they ask good questions of you.

It's a general principle. How do you know, when hiring somebody, if they're confident at their job? The easiest tell is that a good professional asks questions. They try to understand; they help you understand; they ask detailed, nuanced questions; and they don't overstate their promises.

Watch for the opposite. Inexperienced professionals try to please — they say yes to everything and promise the world, because they think that's what people want to hear. Confidence sounds like curiosity. Inexperience sounds like a sales pitch.

You don't need to be technical to spot trouble. If somebody is telling you something is easy, not asking questions, making a lot of assumptions, and doesn't seem terribly interested in deeply understanding you, your mission, and your cause — they're likely going to be difficult to deliver on your vision, and probably a bad experience to work with.

• “It's easy” — said before they understand what you're building.
• No real questions, or only logistical ones — never about your users or your mission.
• A pile of assumptions presented as a plan, with the world promised and nothing qualified.

Founders fixate on ownership — who owns the code, the repo, the accounts. When you're paying for a service where you'll own everything of value produced, ownership is simply a matter of contracts. Get it in writing and move on. The bigger question is harder, and more useful.

It's best to talk about ownership not as things you own, but as responsibilities you're taking on. The question becomes: what do you want to be responsible for and accountable to, versus where can you provide real value? What falls on my plate versus what I expect from you? A good partner walks through that with you honestly instead of letting you assume everything is handled — and a good one starts that conversation before you do.

There's one more thing worth asking now that wasn't on anyone's list a few years ago: how do you actually use AI, and who's accountable for the quality of what it produces? The answer reveals a lot. AI is leverage, never the hero. The danger isn't that someone uses it — it's that they treat it as a magical box that grants wishes and ships whatever comes out.

Here's how I think about it. I treat my AI like a developer I'm coaching — same understanding, same level of tasks, same detail, set up to succeed. Not a magical box that grants wishes, but a relationship I develop over time. The same principles I've used over 20 years coaching others still hold and produce the best results. Coached and reviewed, with a human accountable for every line — that's the answer you want to hear. “It writes the code for us” is not.

Here's the thing: this advice applies to anyone — a freelancer, an agency, or us. The right partner welcomes these questions instead of dodging them. So ask us every one of them: what we'd want to understand about you first, what you'd be responsible for, how we use AI and who's accountable for it. We welcome it — because the questions we ask you back are the whole point.