You’re about to trust a software vendor with your product — and you can’t judge their code. The good news is you don’t have to: everything around the code can be judged before you sign, and that’s what this checklist covers. The video above is the full walkthrough; this is the written version, for skimming — and for sending to whoever signs.
One note on words: we say “agency” throughout, but the checklist is the same whether you’re considering an agency, a freelancer, or an offshore team. It applies to anyone who builds software for you.
Why founders get burned
Founders don’t get burned because they’re careless. They get burned because they can’t judge code quality — and because the things that will actually hit them sit around the code, where nobody points: the deployments, the ownership, the security, everything that happens after the handover. So if you’ve been burned before, it probably wasn’t your fault. You engaged an expert, you judged what you could see, and the important part was invisible.
We’ve seen this from all angles — we’ve worked on projects coming from agencies, delegated work to agencies, and taken over from agencies. And honestly, some of this list we learned by getting it wrong ourselves. Our standard today is a list of things we decided never to let happen again.
What changed in 2026
AI changed this game in two directions at once. On one side, it collapsed the old trade-off between good and fast — but in our experience, only for teams with real discipline. Test automation and solid architecture used to be a budget discussion; they’re now cheap. Which means you should be demanding more for the same money — not the same for less.
On the other side, the same AI lets an undisciplined vendor produce bad software faster than ever. Steve Krouse put it best: vibe code is legacy code. You can now buy a large, buggy legacy codebase in record time. So AI means you’ll be getting more either way — more value, or more debt.
When an agency is the wrong answer
Sometimes it is. When the software is your core product, long-term, and nobody on your side will ever own the tech — Y Combinator has warned founders about that setup for years, and they have a point. And when your budget is under five thousand dollars, hire a skilled freelancer; the agency overhead won’t serve you. The rest of this checklist is for when an agency is the right call.
One thing before the questions: none of them are rude. A good vendor has heard every single one and doesn’t mind, because they have answers. If a question makes the room awkward — that’s feedback too. Speaking as a vendor: the clients we’ve worked with the longest are the aware ones, the ones we’ve had those “uncomfortable” conversations with.
The seven questions to ask before you sign
-
They diagnose before they quote. In the first meeting, give them room and watch what they ask about. The best ones start with your business and your goals, not the project. Be careful with anyone selling a rewrite before they’ve read your code — that’s selling, not diagnosing — and with anyone whose favorite stack is the answer to every question. The strongest good sign of all: they tell you when their own solution would not work.
-
Deliverables on paper. Know exactly what you’re buying: an output (working software), an outcome (a business result), or hours. And what you’re paying for: the result, the effort, or availability. Each is a fair deal — but each carries different risk, and it has to be written down, not assumed. We’ve taken over projects where the budget was drained at fifty percent done, and that’s when the client learned they’d been paying for hours all along.
-
How they use AI — and what it changed. A vague “AI makes us ten times faster” deserves a follow-up: how, and what did it change? Some vendors don’t use it (falling behind); some use it quietly and keep the difference as profit; some pass the savings on and deliver the old thing, cheaper. Our take: even when the work takes the same time, it should be done better — better quality, better scalability, better architecture. Real buyers are pushing on price too — KPMG pressed its own auditor into a double-digit discount by pointing at AI savings — but notice where discounts land: at firms billing by the hour. Decide what you’re buying; cheaper is on the table, but better is usually the bigger prize.
One thing here that points forward: making software friendly to AI — easy for models to develop, and for agents to interact with — is becoming its own engineering discipline, the same kind of shift as moving to APIs ten years ago. If you expect to need it, make sure the codebase will be ready for it. Good answers in this section sound concrete: “we didn’t have budget for end-to-end tests — now we do,” or “we build things to be AI-friendly.” New capabilities — not the old stuff, cheaper.
-
Who carries the risk. With a fixed price, the vendor carries the delivery risk. On time and materials — and here’s the honest part — you own the delivery. Nobody says that out loud, but that’s the deal you’re signing. The fastest way to tell the difference is the warranty question: who pays for the bug that shows up two months after launch? If the contract doesn’t answer it, you just did.
-
The handover standard. When the engagement ends, could a competent stranger — or an AI agent — pick up the codebase next month and safely make a change? Tests, docs, automated deployments: that’s what the handed-over package should include. Worth adding: “if we grow an in-house team, can you work alongside them?” Your local team is going to grow, especially on the funding journey.
-
Their delivery standard, end to end. What does QA look like? How do they handle security and keep the platform reviewed and updated? What does maintenance look like after launch? Here’s the trick: you’re not judging the content of the answers — you’re checking that rehearsed answers exist at all.
-
Start small. A fixed-price, closed-scope first engagement with milestone payments tied to deliverables you’ve accepted. It closes the loop at small scale — how you communicate, how you agree on expectations, how delivery actually feels. For team augmentation: a two-week trial ending in a clear deliverable. The trial tests everything the first six questions asked about — against reality, instead of answers.
The paperwork: four things that must be in writing
- Paying is not the same as owning. Only a written transfer of intellectual property makes the code yours — access to the repository is not legal ownership. Check what the vendor keeps: their pre-existing tools and components, which is fair. Protect your IP, and let them protect theirs. There’s a saying: one client in a vertical is a client, two is a conflict, three is specialization — know where you’re leveraging their expertise, and land on fair terms.
- Acceptance. Agreed criteria and a defined window to review each milestone — usually around five working days — with payment releasing on written acceptance. That’s what makes milestones real. One caveat: when work is sequenced, dragged-out reviews disorganize everything, so negotiate a healthy buffer and expect pushback if your reviews drag.
- An exit clause. Termination for convenience — roughly thirty days’ notice and a capped exit fee. It’s the clause that lets you leave without a lawsuit.
- Warranty, with numbers. The market norm is thirty to ninety days after acceptance for real defects, sometimes up to one hundred eighty. That’s your answer to the bug two months after launch.
Three signs of a healthy engagement
You can’t always review the code — so watch the delivery instead.
- Working software, delivered early and often. Weekly or bi-weekly demos of running software, not slide decks about progress. A big final reveal after months of work is a big final risk — yours.
- They build in the open. Commits and pull requests landing where you own them, as they happen — not “it’s almost ready, we’ll commit later this week.” Visibility isn’t a report; it’s watching the work land.
- Communication keeps you in the loop — and in control. A named delivery manager, product demos every sprint, budget and scope check-ins. Scope changes surfaced ahead, with their cost and date impact — not at the invoice. And the standing ability to change direction, to the extent you agreed.
Three rules for when they leave
Every engagement ends, and the good ones are designed to.
- Ownership transfers on a milestone — not “at the end.” A vendor holding ownership until they’re paid is fair; tie the transfer to the first paid milestone, not to the end of the relationship. From that point: repository, cloud, domains, pipelines — in your name, with the vendor holding access you can revoke. Clients do get held hostage — by code, by infrastructure, by a domain. We’ve seen a client strong-armed into paying extra just to get their own domain back when paths split. If nobody can state the ownership terms, you’re locked in by default.
- Make the knowledge transfer a deliverable. Handover docs and recorded walkthroughs, written into the scope — because when the contract ends, the understanding walks out the door unless you caught it first.
- Leave-by-design is the green flag. A vendor whose business survives you leaving has their incentives aligned with yours. Lock-in is a business model — not an accident.
The pattern
Everything on this list is one idea seen from different sides: discipline you can observe, risk on the vendor’s side, and ownership on yours. When those three hold, the details take care of themselves.
And the reason it matters right now: every few years, software has to be re-done, and the shift this time is that systems are becoming agentic — built for AI to operate them, and open enough to plug into everything around them. The vendor bar moves with every wave. That’s why the handover question — and the quality question — belongs in every vendor conversation this year.