How to choose a development agency when you can't read code

Choosing a development agency as a non-technical founder feels like choosing a surgeon by their waiting room. The thing you are actually buying, engineering judgment and code quality, is the thing you are least equipped to evaluate. Portfolios all look polished. Testimonials are curated by definition. Every sales call features the word "senior."

Here is the good news, learned from both sides of the table: you do not need to read code to evaluate an agency, because process leaks the truth. How a team behaves in the sales conversation, what it puts in the contract, and what it promises about visibility are all reliable proxies for how it builds. We run an agency at Novek Labs, we have inherited the wreckage of bad engagements often enough to know exactly where they go wrong, and every signal below is checkable before you sign anything, with no technical knowledge required.

A disclosure that doubles as advice: we wrote our own process to pass these checks, so yes, this guide flatters us. Run it on us anyway, alongside everyone else you are evaluating. The checklist only works if you apply it to the people who wrote it.

Key takeaways

• Evaluate process, not portfolios. Operational transparency predicts delivery quality almost one-to-one.
• The seven signals: scope behavior, price shape, demo cadence, ownership terms, portfolio specificity, team identity, and exit design.
• The contract needs five clauses regardless of who you choose: your repos from day one, full IP assignment, your accounts, written scope with exclusions, fixed price against that scope.
• One reference call with the right questions beats twenty testimonials.

Signal one: what they do with your scope

Describe your idea in the first conversation and watch what happens to it.

A weak agency agrees with everything, because everything is billable. Your feature list is met with enthusiasm, your timeline with confidence, your budget with flexibility. It feels wonderful and predicts disaster, because the padding for all that agreement gets paid later, by you, in overruns.

A serious agency starts cutting immediately. Expect questions like "what is the one thing this product has to prove?" and expect features you love to be moved to a v2 list in front of you, with reasons. Early, specific pushback is the agency spending its sales-call goodwill on your outcome. In our own discovery conversations, the moment a founder pushes back on a cut and we work through it together is usually the moment both sides know the engagement will work.

Green flag: they argue with your scope before they have your money. Red flag: the first "no" you hear is scheduled for after the deposit.

Signal two: whether the price is a number or a meter

Hourly billing on a first product puts every risk on you: the team's estimation mistakes, their slow weeks, their learning curve on your domain, all billable. The alternative, fixed scope at a fixed price, forces the agency to estimate carefully and to eat its own mistakes, which is precisely the incentive you want operating on your behalf for ten weeks.

There is a legitimate place for time-based billing: open-ended collaboration on an evolving product, embedded team extensions, genuine research. A v1 build is none of those. It is a definable artifact with a definable end, and professionals who build them constantly can price them.

The tell is what happens after discovery. An agency that runs a paid discovery week and still will not commit to a number is telling you it does not trust its own estimates. Believe them, and leave.

Green flag: "after the discovery week you get a fixed scope, a fixed price, and a launch date." Red flag: "we estimate 400 to 900 hours depending on complexity."

Signal three: when you see working software

Ask this exact question: "How often will I see the actual product running, and how?"

The only good answer is weekly, live, on a staging link you can open yourself and click through. Not slide decks. Not sprint reports. Not screen recordings, which show the twenty seconds that worked. A team that demos working software weekly cannot hide a stalled project, because the stall would be visible within seven days. A team that resists the commitment is reserving the right to stall invisibly.

This one signal carries more predictive weight than any other on the list. In every failed engagement we have been hired to rescue, the demos stopped before the schedule slipped. The silence is always first. We keep our own weekly demo cadence non-negotiable for exactly this reason, and we wrote about the failure pattern at length in Why most MVPs die before launch.

Green flag: a staging URL exists from week two and you have the password. Red flag: "we do a big demo at the end of each milestone."

Signal four: who owns what, from day one

Five contract clauses, all standard among professionals, all non-negotiable regardless of which agency you choose:

1. The code lives in repositories you own from the first commit. Not shared at the end, not mirrored monthly. Yours, always, with the agency working inside them.
2. Full IP assignment to you, in writing, not a license and not conditional on anything beyond payment for the work performed.
3. Every account is created under your ownership: hosting, domains, app stores, analytics, third-party APIs. The agency gets access; you hold the keys.
4. A written scope with an explicit exclusions section. A scope that only lists inclusions is half a document, and the missing half is where disputes live.
5. Documentation as a deliverable, sufficient for a successor team to take over without archaeology.

An agency that keeps the repo "for convenience during the build" has created a hostage situation, whether or not it ever intends to use it. The professional ones volunteer all five clauses before you ask, because clean exits are how they keep their reputations. The ones that resist have answered your real question early and cheaply.

Signal five: what the portfolio actually claims

Ignore the visuals. Screenshots prove the existence of a designer, nothing more. Read the portfolio for specificity and survivorship instead:

• Are projects named, or is it "a leading fintech client" all the way down?
• Does it say what the agency actually did? "Design and full-stack build, launched in nine weeks" is a claim. "Partnered to drive digital transformation" is fog.
• Do the products still exist when you search for them? Dead links under portfolio pieces are data.

Then ask for one reference call with a past client whose project resembles yours in size and shape. The reaction to the request is itself a signal: comfortable and fast means the relationships survived; hedging means they did not. On the call, skip "were you happy" and ask questions that surface process truth:

• How often did you see working software?
• When something went wrong, how did you find out: from them, or by noticing?
• Did the price move after signing, and why?
• Who did you actually interact with week to week?
• Would you use them again for the next product, and are you?

Five minutes of specifics beats any number of logos on a homepage.

Signal six: whether the seniors you meet are the seniors you get

The classic agency bait-and-switch is organizational, not technical: partners and leads run the sales conversation, then the project lands with whoever is available, and the seniors you chose the agency for reappear at invoice time.

Ask directly: who will design this, who will write the code, and who do I talk to each week? Then ask whether the people named are the people on the call. In a small studio the answer is structurally guaranteed, which is one honest advantage small senior teams have over large mixed ones: on a first product, where every decision is architectural, there is no room for someone learning on your budget.

Green flag: named humans, on the call, who will personally build it. Red flag: "we'll assign the right resources from our talent pool at kickoff."

Signal seven: how they talk about the end

Ask what happens when the engagement finishes. You are listening for two things: a concrete handover story (documentation, credential transfer, architecture walkthrough, availability for the successor team's questions) and a support model that is offered rather than imposed.

What you do not want is a structure where leaving is painful by design: proprietary frameworks only they can maintain, undocumented deployment rituals, licenses instead of ownership, hosting resold through their accounts. Agencies with confidence in their work make themselves easy to fire, which is precisely why clients keep them. The best endings we have had as a studio are the ones where we helped interview the client's first engineering hires and handed them a documented codebase; several of those clients came back with their next product, which is the whole model working as intended.

Green flag: the handover process is described with the same specificity as the build process. Red flag: vagueness about anything that happens after the last invoice.

The pattern behind all seven

Every signal above is one test wearing seven costumes: does this agency make its own claims checkable? A fixed price is a checkable estimate. A weekly demo is checkable progress. An owned repository is a checkable exit. A named team is a checkable promise. Serious teams volunteer verification because verification is where they win. Teams that resist it have a reason, and the reason is never in your favor.

This also explains why the evaluation does not require technical skill. You are not auditing code. You are auditing whether the agency structurally exposes itself to being caught, and that is legible to anyone.

Frequently asked questions

Should I pick the agency with the strongest portfolio? Portfolios establish a floor, not a ranking. Past a baseline of real, live, specific work, the process signals above predict your outcome far better than portfolio polish, which correlates mainly with the agency's marketing budget.

Are cheaper agencies always worse? No, and expensive ones are not always better; geography moves rates more than quality does. What correlates with quality is the shape of the engagement: fixed scope, weekly demos, clean ownership. A cheap agency with those terms beats an expensive one without them.

How many agencies should I evaluate? Three serious conversations is usually enough to feel the difference, because the signals are contrastive. The scope-cutting agency stands out sharply once you have heard two rounds of enthusiastic agreement.

What if I already signed with an agency that fails these checks? Renegotiate the checkable parts now: repository transfer, a staging link, a demo cadence. Frame it as process, not distrust. A decent team will accommodate all three within a week; the reaction to the request tells you whether the engagement is salvageable. If you are already stalled, the rescue sequence in Why most MVPs die before launch is the playbook.

Is a freelancer or a first hire better than any agency? Sometimes, and the honest comparison depends on whether you can spec and verify the work yourself and whether demand is already proven. We wrote the full decision framework in Freelancer, agency, or first hire.

Run the checklist on us

Our process is documented step by step, services state scope, deliverables, and ownership terms in plain language, and the weekly demo cadence is in writing before any engagement starts. If you are evaluating teams for a build, start a conversation and grade the first call against the seven signals above. That is what the checklist is for.