Developer for Non-Technical Founders

The hard part of hiring without a technical background isn't the work — it's that you can't independently check it. That asymmetry creates a few concrete failure modes:

• Scope you can't price. When you can't estimate effort, you can't tell whether "two more weeks" is honest or padding. Agencies bill against scope you have no way to challenge.
• The 80%-done trap. A demo looks finished. Then payments, edge cases, error states, and data migration — the unglamorous 20% — turn out to be most of the real work, and launch slips.
• Lock-in by obscurity. A build with no documentation or types works fine until the original developer disappears. Then your next hire quotes a rewrite because reading the old code costs more than starting over.
• The verification gap. "It's done" means nothing if you can't test it yourself.

None of these require you to learn to code. They require an engagement where outcomes, not code, are what you sign off on.

You can vet a developer without reading a line of code. These questions surface process, not syntax:

• "Walk me through your last project from first call to handover." A specific answer means a repeatable process. Vague answers mean every project is improvised.
• "What will I own when we're done?" The right answer includes source code in your accounts (GitHub, hosting, database) and all credentials — not locked inside their agency.
• "Show me a project you handed off to someone else." Code another developer picked up cleanly is the real test of maintainability.
• "What happens when something's wrong after launch?" Listen for whether bugs are treated as a normal part of the lifecycle, not a surprise.

Then check it yourself: visit their live projects and click around. A booking SaaS like BookBed (Flutter + Firebase + Stripe, with bidirectional iCal calendar sync) is a running product you can poke at — more telling than any portfolio screenshot. Ask for the staging URL of your project at each milestone and use it. If you can use it, it's real.

A workable engagement runs on three things: a written spec you approve before any code, milestones you can see and test, and a handover you actually own.

The spec is plain-language: what the product does, who uses it, what each screen shows, what happens when things go wrong. You sign off on this, not on architecture diagrams. It's also your defense against scope creep — changes become visible decisions, not silent rebuilds.

Milestones mean working software at each checkpoint, not progress reports. You log in and try it against the spec.

Realistic timelines, working solo with AI-augmented tooling (no account-manager layer in between):

• Clickable prototype: about 1–2 weeks.
• Focused MVP (one core flow, auth, payments, a real database — the shape of Pizzeria Bestek on React + Supabase): commonly 6–10 weeks.
• Multi-feature SaaS with billing and sync (BookBed's complexity): 3–5 months.

These depend on how settled the spec is. A clear spec shrinks the range; a moving one widens it. I won't quote a number without seeing your scope — anyone who does is guessing.

Walk away, or at least slow down, if you see these:

• No written spec, just "trust me." If they won't put scope in writing, you have nothing to hold the work against.
• Code and accounts stay with them. If you don't get your own GitHub, hosting, and database, you don't own your product — you're renting it.
• An account manager between you and the builder. Every layer adds cost and loses detail. You should talk to the person writing the code.
• Estimates with no spec. A firm price or date before scope is defined is a sales tactic, not an estimate.
• No staging environment. If you can't see and test the work in progress, you're paying on faith.
• "We'll document it later." Documentation written at the end is documentation that never gets written. It should grow with the build.

The through-line: every red flag is a place where you'd have to take someone's word for it. A good engagement removes those — you sign off on outcomes you can see, and you walk away owning everything.