What to Ask the People Who Are Going to Build Your Software

Hiring custom software development has an asymmetry problem: whoever's selling knows a lot more than whoever's buying, and both sides know it. The usual consequence is that the conversation gets decided by trust and by price, which are the two worst criteria available.

These are the questions we'd want people to ask us. Each comes with the answer that should set off a warning light, because a question with no way to judge the answer isn't worth much.

And yes, we're writing this knowing you'll ask us these too.

1. Who's actually going to write the code, and will I talk to that person?

Bad sign: the first call is with someone who won't touch the project, or they introduce you to "the team" without names.

Every layer between you and whoever's building loses the nuance that made your case different from the one next door. Ask who'll be on it in month six too, not just week one.

2. How do you estimate, and what happens if the estimate falls apart?

Bad sign: a fixed number given over the phone, before the problem's even been scoped.

Nobody can confidently estimate something they haven't defined. What you can ask for is a short, paid discovery phase with a real deliverable — scope, risks, and a number — and clarity on what happens when something goes sideways: whether the vendor absorbs it, whether you pay for it, or whether scope gets cut.

Be just as wary of the one who gives you an instant number as the one who refuses to commit to any.

3. When will I see working software?

Bad sign: "at the end," or weekly progress reports instead of the actual application.

A progress document can't be used. A deployed application can, and using it is the only way to discover that what you asked for wasn't what you needed — while it's still cheap to fix. If the first time you touch the product is at delivery, the entire risk is yours.

4. Who owns the code, and where does it live?

Bad sign: "on our platform," licenses for some proprietary framework, or a repository you don't have access to.

It should be in your repository and your cloud from day one. The litmus test: ask what you'd have to do to take the project to a different provider next month. If the answer is uncomfortable, you already know how much your negotiating power will be worth a year from now.

5. What happens to what I already have installed?

Bad sign: assuming everyone will be on the latest version.

This one always gets forgotten, and it's where real projects break. If you have a published app, integrations, or an API used by third parties, there are clients you can't force to update. We wrote about this after migrating LoverCast's schema without breaking installed apps, and the lesson was that "zero breakage" is almost never zero: what you actually get to do is decide up front what degrades, for whom, and for how long.

Ask exactly that. If they answer that nothing will break, they either haven't understood you or haven't thought it through.

6. How will we know if it works?

Bad sign: "when it's done."

That's a weak answer for anything, but it's critical when AI is involved. An assistant that's right 90% of the time gets the other 10% wrong with total confidence, and all the engineering lives in that 10%: detecting it, bounding it, and deciding what happens when it hits. If nobody proposes a metric before picking the model, what they're selling you is a demo.

We hold our own products to the same standard: Isobaria publishes how often each model gets it wrong, with the evidence archived and the limitations written down. It's uncomfortable, and it's the only way the number actually means something.

7. What won't you do?

Bad sign: everything fits. If your project slots perfectly into their catalog, either you're very lucky or they're saying yes to everything.

A provider who knows what they're doing also knows what they don't do, and saying so early is the only thing that makes the yes credible. Our service pages carry a "when we're not the right fit" section for exactly this reason.

8. What happens after launch?

Bad sign: the budget ends the day of deployment.

Shipping is the beginning. App stores require maintenance, operating systems migrate, dependencies expire, and the first real week always brings surprises. Ask who answers at three in the morning, how a fix gets deployed, and whether it can be rolled back. If deploying a change is an event, it'll happen rarely, and each release will carry more risk than the last.

What we take away from this

None of these questions are technical. Anyone can ask all of them without knowing how to code, and every one of them can be answered on the first call.

If asking them makes you uneasy, pay attention to that unease: you're about to sign a months-long project with someone you're afraid to ask how they estimate. Any provider worth your money would rather you asked.

Our own answers are written down in the method, specifically so you can use it on the first call to hold us accountable. If you've got a project in mind, tell us about it.