How to Hire and Manage a Dev Shop When You're Not Technical

The email arrives on a Tuesday. "Quick update: we're at about 90%, just polishing a few things before we show you." It's the third week you've heard 90%. You've paid $110,000 of a $140,000 project. You ask for a link you can click. You get a screen recording instead, and something cold settles in your stomach that you can't quite name.

I can name it. I've spent nine years as a fractional CTO on both sides of this table: hiring dev shops, managing them, auditing them, and being the person founders call on that Tuesday. The autopsy is depressingly consistent. The shop wasn't evil. The founder wasn't stupid. The project was lost months earlier, in decisions nobody realized they were making.

This is the guide I wish I could send those founders before the first contract. It's long, because the problem deserves better than five tips. Read it once now, then keep it open the day you start talking to shops.

The trap is structural, not moral

Start with why this goes wrong so often, because it's not the reason founders assume.

When your accountant produces bad numbers, reality corrects you within a quarter. When a dev shop produces bad code, the product can look flawless in every demo while the foundation quietly rots. You are buying the one professional service where the buyer cannot inspect the goods. That's the information gap.

Now add the incentive gap. Saying "yes" costs a shop nothing today. Saying "no, that feature is a mistake, and here's why" risks the invoice. So most shops drift into becoming order-takers, and an order-taker with a non-technical client is a machine for building the wrong thing efficiently. Nobody planned this. It's just where the incentives roll downhill.

Everything in this guide is a counterweight to those two gaps. You will not learn to read code by Friday. You don't need to. You need to run the engagement like a professional buyer, and that is entirely learnable.

2026 complication: the demo got cheap

One thing has genuinely changed in the last three years, and most advice on this topic hasn't caught up.

A working demo used to be reasonable evidence of engineering competence. It took real skill to make software look finished. That signal is now broken: with modern AI coding agents, an impressive demo costs an afternoon. The gap between demo-quality code and production-quality code has never been wider, and the shops most eager to dazzle you in week one are often the ones renting the dazzle from a model.

This cuts both ways, though. Shops that use AI well are genuinely, dramatically faster, and you want that speed working for you. The difference between the two kinds of shop is one question:

"How does your team use AI tools, and who reviews what they produce?"

A serious team answers specifically: which tools, what gets AI-drafted versus hand-built, and what review, testing, and security checks stand between generated code and your product. The two failing answers are "we don't use AI" (you'll pay 2023 prices for 2023 speed) and "extensively!" with silence about review (you'll get tech debt at machine speed).

The same shift hands you a new weapon. You can now sit with an AI tool for a weekend and build a rough prototype of your own idea. Do it. A clickable prototype is the best project brief ever invented; it kills more ambiguity than fifty pages of requirements. Just be honest with yourself and the shop about what it is: a sketch to build from, never a codebase to ship.

Choosing: judge them by their questions

Before you talk to anyone, write one page: the problem your product solves, who the users are, the single metric that defines success, what already exists (designs, that weekend prototype, an old codebase), and your honest budget range. Not a spec. A brief. Writing it forces decisions that otherwise get made silently by whoever you hire.

Then send it out, and when the calls start, mostly ignore the portfolio. Portfolios are marketing. Count the questions instead. A senior team interrogates your business: Who pays? Why would they switch to you? What's the smallest version that proves the idea? What happens if this fails? A team that asks nothing and quotes fast is showing you exactly how they'll build: fast, unquestioning, and wrong.

The other signals worth trusting:

• Have they ever told you no? If they haven't pushed back on a single idea before the contract is signed, they never will after. You're not paying for agreement; agreement is free.
• A detailed quote without discovery is a sales number. Nobody can honestly price a product from one call. Prefer a small paid discovery phase, a week or two at modest cost. You'll learn more from one real deliverable than from ten sales meetings, and you can walk away cheaply.
• Meet the people who will actually write the code. Many shops sell with senior faces and deliver with whoever's free. Ask for names and get them into the contract.

And about those three quotes sitting in your inbox at $40k, $90k, and $150k: that's not cheap versus expensive. That's three teams silently pricing three different products. One is a demo, one is a product, one may just be padding. The spread isn't information about price. It's information about how vague your scope still is.

The contract: make yourself impossible to hold hostage

Almost every dev shop horror story ends the same way: the relationship sours, and the founder discovers the shop is holding something they need. The code. The AWS account. The domain. The app store listing. The entire game of contract design is making sure that moment has no leverage in it. Five clauses do it, all standard, so resistance to any of them is itself a red flag:

1. IP assigned continuously, not on final payment. Work-for-hire, owned by you as it's written, so a dispute in month four can't hold your product ransom.
2. Everything lives in accounts you own. Code in your GitHub organization. Infrastructure in your cloud account. Domain in your registrar. App listings under your developer account. The shop gets access; you hold the keys. This one clause defuses nearly every hostage scenario, because there's nothing left to hold.
3. Milestones tied to acceptance criteria. Each payment unlocks against working software you can click through, judged against a written definition of done. Never against a progress report.
4. An exit clause with a handover obligation. Either side can leave with notice, and leaving obligates a documented handover. You'll probably never invoke it. Its existence changes behavior anyway.
5. Named humans. The people you interviewed are the people on your project, and substitutions need your sign-off.

Running it: manage outcomes, not tasks

You can't manage developers task by task. You don't have the vocabulary, and micromanaging a craft you don't practice irritates everyone while catching nothing. What you can do, better than anyone alive, is manage outcomes for your own product. Four habits cover it.

A weekly demo of working software. Not a status call, not a deck. Software, running, that you can touch. Given what AI did to demo costs, add one refinement: rotate what you ask to see. "Show me the same flow on a phone." "Show me what happens with a wrong password." "Show me last week's feature again, today." Polished happy paths can be rented; consistent depth across weeks cannot.

A staging link you can open anytime. The current state of the product, always live, no appointment needed. If the shop resists, ask yourself why the current state can't bear looking at. Every honest answer to that question is bad news.

Every scope change in writing, with a price. Scope creep kills more projects than incompetence does. One line per change is enough: "Adding social login, +1 week, +$4k, confirm?" The ledger protects both sides, and you'll discover which of your "tiny tweaks" cost three weeks, which is information you badly need about your own instincts.

The two-week rule. Two consecutive weeks without demonstrable progress means something is wrong: the wrong person got assigned, a technical hole is being quietly dug around, or your project is parked behind a louder client's. Ask once, directly. Whether the answer is a straight explanation or a fog of reassurance tells you whether you have a bump or a pattern.

The quarterly health check

Five questions, none of which require reading a line of code. Each has a right answer. Run them every quarter, or the moment your gut tightens.

• "Show me the repository activity." You're looking for steady commits from the named team. Long silences, or one person doing everything, contradicts what you're paying for.
• "Could a new developer set this up from the documentation alone?" If the honest answer is no, your product exists only in a few heads, and those heads work for someone else.
• "If traffic multiplied by ten tomorrow, what breaks first?" Senior teams have a specific answer ready. I run a promotions platform where a national campaign can do exactly that overnight; you want this conversation before launch day, not during it.
• "When did we last restore a backup?" Not "do backups exist." Restore. An untested backup is a hope with a cron job.
• "What would you build differently if you started today?" Every honest team has regrets. "Nothing" is the answer of a team that has stopped thinking, or stopped telling you the truth.

When you need someone in your corner (and when you don't)

Here's the part where a consultant is supposed to tell you that you need a consultant. Let me try to earn your trust instead.

If your project is modest, your shop came through a referral you'd stake money on, and failure would bruise you rather than break you, this guide plus your own diligence is probably enough. Plenty of outsourced projects succeed with nobody technical on the client's side. Run the checklist, keep the cadence, and you'll be ahead of 90% of buyers.

The math changes as the stakes climb. Six figures committed. A product that is the company. Health-check answers that made your stomach do the Tuesday thing. At that point the missing piece is a technical leader who works for you and not for the shop: someone who reviews the architecture before it hardens, translates demos into truth, and turns "almost done" into a date. That's the job of a fractional CTO, at a fraction of a full-time hire, and it typically pays for itself in avoided rework before the first quarter is out. The most common thing founders tell me after we start isn't about technology at all. It's relief. Someone finally explains what's actually happening, in plain English, and the pressure of not-knowing lifts.

Whichever way you go, go in as a professional buyer. The founders who get burned aren't the ones who knew too little about software. They're the ones who ran a six-figure engagement with less rigor than they'd apply to hiring an office manager. As of today, that's no longer you.

The checklist