Choosing who builds your software is one of the highest-stakes decisions a non-technical founder makes, and one of the hardest to judge from the outside. Everyone's portfolio looks good. Everyone says they're senior. Everyone promises to ship on time.
We've been on both sides of this table — hiring contractors for our own products, and being hired to build other people's. Here is the checklist we'd give a friend who asked, "how do I not get burned?"
Judge on evidence, not the pitch
A pitch deck proves someone can make a pitch deck. Ask for something harder to fake.
Ask to use software they operate, not just screenshots of it. Anyone can show you a beautiful mockup. Far fewer can hand you a live product they run in production, with real users and real uptime responsibility. A team that carries the pager for its own software builds differently for yours — they've felt what breaks at 2 a.m., what users abandon, and what a feature costs to keep alive. That operating scar tissue is the thing you're actually buying.
Ask who, specifically, will write your code. Agencies often sell you senior engineers and staff you with juniors once the contract is signed. Ask for the names, and ask whether the people scoping your project are the people who will build it. If there's a wall between the pitch team and the delivery team, expect a game of telephone with your product on the line.
Insist on a written scope before anyone writes code
The most expensive failures don't happen in the code editor. They happen in the gap between what you asked for and what the other side understood.
A serious partner closes that gap on paper first: a written scope you both sign, an agreed architecture, and a plan for how changes get handled when — not if — they come up. If someone wants to "just start building" from a verbal brief, that's not agility, it's a change-order business model. The vague scope is the invoice's best friend.
You don't need a full specification to start the conversation — a paragraph about the problem is enough. But you should not start the build without a scope you understand.
Listen to how they talk about failure
The most revealing interview question is not "what have you built?" It's "tell me about a project that went sideways, and what you did."
A partner worth hiring answers plainly: here's what we missed, here's what it cost, here's what we changed. A partner to avoid gets defensive, blames the client, or claims nothing ever goes wrong. Software always goes sideways somewhere. What matters is whether they'll tell you early and honestly, or manage you with green status reports until the deadline arrives red.
The same honesty should show up in estimates. Ask what a timeline assumes and what would change it. "Six weeks" with no assumptions attached is a wish. "Six to nine weeks, depending on how the payment integration behaves, and here's what we'll know after the first two" is an estimate from someone who has done this before.
Get ownership in writing
This one is simple and non-negotiable: you should own the code and IP.
On full payment, a trustworthy partner transfers the source, documentation, and deployment pipelines to you. Their reusable internal libraries can remain theirs — that's normal — but the product you paid for is yours, and you should be able to take it to another team without a hostage negotiation. Confirm this in writing before the first commit, not after the relationship sours.
Ask what happens after launch
Launch day is where a lot of agencies quietly disappear. The site goes live, the invoice is paid, and the relationship ends — right when the real questions start arriving.
Ask what support looks like after go-live. Who fixes the bug found in week three? Who applies the security patch in month six? Is there a named person who knows your system, or do you file a ticket into a void? A partner who treats launch as the start of the product's life, not the end of theirs, is worth more than one who quotes ten percent less and hands you a repository and a goodbye.
The strongest signal of all
Here's the counterintuitive one. The best partners will sometimes tell you not to build something.
An agency optimizing for billable hours says yes to everything. A partner optimizing for your outcome will occasionally say: you don't need a custom app for this, a well-configured off-the-shelf tool will do; or, that AI feature you want is the wrong tool for this job; or, this scope is bigger than the problem justifies. When someone turns down work because it isn't in your interest, believe the rest of what they tell you.
A short checklist to keep
- Can they hand me software they operate in production, not just show me pictures of it?
- Will the people who scope it be the people who build it?
- Is there a written scope before the build starts?
- How do they talk about a project that failed?
- Do I own the code and IP, in writing, on payment?
- Who supports it after launch, by name?
- Have they ever told a client not to build something?
None of these require you to read code. All of them are things a straight-talking partner will answer without flinching — and a place to be careful when the answers get slippery.
Createawity builds and supports software for founders and enterprises, and runs its own products in production. If you're weighing a build, tell us what you're building — we'll tell you what it honestly takes, including when the honest answer is that you don't need us for it.