Hiring a partner to build software or AI systems is mostly a trust decision, and you have to make it before you have much evidence. The sales call is the only data point most buyers get, and a good salesperson is not the same thing as a good engineering team. The questions below are designed to surface the difference. They are blunt on purpose, and a few of them might point you toward a different shop than ours. That's fine. A good partner survives hard questions.
1. Who owns the code, the models, and the accounts?
Get this in writing before anything else. You should own the source code outright, the cloud and API accounts should be registered under your company, and any fine-tuned models or prompt assets built for you should belong to you. Watch for arrangements where the partner hosts everything on their accounts "for convenience." That convenience becomes leverage later. The healthy default is that on the day you part ways, you can keep operating without them.
2. Who will actually do the work, and how senior are they?
Agencies sell with their best people and staff with their cheapest. Ask directly: who writes the code, how many years have they been doing this, and will that change after the contract is signed? It's reasonable to have junior engineers on a team; it's not reasonable for juniors to be unsupervised on your hardest problems. Ask who reviews their work and how often.
3. How do you handle quality on AI specifically?
This is where AI work diverges from normal software. Traditional code is deterministic; a language model is not. If a partner can't explain how they measure whether the AI is actually doing its job, that's a red flag. Listen for concrete practices:
- Evaluations (evals), test sets that score model output against known-good answers, run repeatedly as things change.
- Guardrails for the cases where the model is wrong, because it sometimes will be.
- A plan for monitoring quality in production, not just at launch.
"We tested it and it works" is not an answer for a system whose behavior shifts with every prompt and model update. Our own take on this lives in our AI systems work, but the principle holds regardless of who you hire.
4. What does your testing and review process look like?
You're not asking for a lecture on test coverage. You're asking whether shipping is careful or careless. Do changes get reviewed by a second person before going live? Is there automated testing? What happens when something breaks in production at 2 a.m., is there a real process, or does it depend on one heroic individual? The answer tells you how the next year will feel.
5. How often will we talk, and who is my point of contact?
Communication cadence is a leading indicator. Decide up front how often you'll get updates, in what form, and who you can reach when you have a question. A weekly written update plus a standing call is plenty for most projects. Be wary of two extremes: silence between invoices, and a flood of activity that never adds up to working software.
6. Can I see something real every week or two?
Long projects with no visible output until the end are how budgets disappear. A good partner ships in small, reviewable increments, a working feature, a demo, a deployed change you can click on. If the first thing you'll see is the finished product months from now, you have no way to course-correct, and neither do they. You can see how we structure this on our process page.
7. What happens at handoff?
Every engagement ends. Ask what the end looks like before you begin. A clean handoff includes documented systems, credentials transferred to you, a walkthrough for your team, and code that someone else can pick up without a translator. The opposite, undocumented systems only the original team understands, is a quiet form of lock-in that costs you for years.
8. How locked in will I be?
Lock-in isn't only about code ownership. It's also architecture choices that make you dependent. Ask whether they build on standard, widely-supported tools or on proprietary platforms that only they know. Ask how hard it would be for a different team to take over. The honest answer might include some lock-in, most real systems have some, but you want a partner who names it instead of hiding it.
9. Tell me about a time you told a client no.
This is the most revealing question on the list. A partner who has never pushed back on a client either isn't being honest or doesn't have the judgment to. The best engineers say no to features that won't work, timelines that aren't real, and AI use cases where the technology isn't ready. If they say yes to everything in the sales call, they'll say yes to scope creep later, and you'll pay for it.
10. What would make you walk away from this project?
A serious partner has limits. Maybe it's a use case they don't think AI can reliably handle yet. Maybe it's a timeline that guarantees a bad result. Hearing a real boundary is reassuring; it means they're optimizing for the work going well, not just for closing the deal.
11. Can I talk to two references, including one that didn't go smoothly?
Anyone can produce a happy reference. Ask for one where things got hard. How a partner handled a delay, a disagreement, or a missed estimate tells you far more than a glowing quote. When you get a reference on the phone, ask what surprised them and what they'd do differently. You can also look at what a shop has actually shipped, our work is public for that reason.
12. How do you price, and what happens when scope changes?
Understand whether you're paying fixed-bid, time-and-materials, or a retainer, and what each means for risk. Fixed bids push risk onto the partner but invite corner-cutting; time-and-materials needs trust and tight communication. Either can work. What matters is that change requests have a clear, agreed process so you're never surprised by an invoice.
A short takeaway
You don't need all twelve answers to be perfect. You need the partner to engage with the hard ones honestly, to admit trade-offs, name lock-in, and tell you about the project that went sideways. Dodging is the signal. A shop that welcomes these questions is showing you how they'll behave when something goes wrong, which it eventually will. If you want to put these questions to us directly, get in touch. And if our answers send you elsewhere, that's a good outcome too.