The Lovable and Bolt boom created a weird hiring market: founders with real traction, real revenue, and codebases they cannot personally judge. That gap gets filled by $200/hr "AI engineers" who can demo fast but cannot explain a Postgres query plan, a migration rollback, or what happens when Supabase hits connection limits.
If you are a non-technical founder preparing to hire a senior engineer, your job is not to become one first. Your job is to grade the signals around the code. Think of this as a first engineer playbook for vetting developers when you cannot read every line yourself.
A reverse code review and a paid trial do not make hiring safe. They make the risk visible before you commit to six months of salary, roadmap delay, and cleanup work.
You cannot grade code, so make every candidate grade yours
The worst interview starts with abstractions: "Tell me about your experience," "Are you good with Supabase," "Can you scale this app?" Anyone can answer those questions well for 45 minutes. The better interview starts with your actual repo.
Before you call candidates, ask any junior developer or technical friend to pull three artifacts from the codebase: the top 20 most-changed files, the list of external services the app calls, and the 3 areas that scare you most. For a post-Lovable product, that usually means auth, payments, and the AI feature. Give every candidate the same packet and ask them what worries them.
This is the reverse code review approach Jacob Kaplan-Moss formalized in 2021: instead of you reviewing the candidate's code, the candidate reviews yours. You do not need to know whether their diagnosis is perfect. You need to compare five answers to the same file and notice who asks useful questions, who jumps to rewrite, and who can explain risk without performing technical theater.
Imagine you're running a B2B workflow app with 400 active users and Stripe billing glued into a Supabase table. One candidate says, "I'd rewrite this in a fresh Next.js app." Another says, "I need to understand how subscription state moves from Stripe webhook to database row to UI access before touching it." The second person is already acting like an owner.
GitHub shows behavior, not seniority
GitHub is useful, but not in the way founders think. Green squares are weak signal. Ben Frederickson's GitHub Archive analysis found that only about 17% of users pushed public code in the prior year. The exact number is old, but the lesson still holds: many strong engineers spend most of their time in private repos.
Look for behavior instead. Issues and pull requests on other people's repos show how the candidate thinks in public: do they write clear bug reports, disagree politely, and review code with context? Commit messages also tell a story. "fix" tells you almost nothing; "fix: short-circuit Stripe retry loop on 402 to prevent duplicate charges" tells you they understand cause, effect, and production risk.
Language breadth is another place where founders get fooled. A senior engineer is usually deep in 2 or 3 stacks, not magically senior across 8 languages and every framework on the homepage. If they claim React, Node.js, PostgreSQL, Swift, Kotlin, Rails, Python, LangGraph, and Kubernetes with equal confidence, ask them which 2 they would bet your company on.
No public GitHub is not a red flag by itself. Refusing to show any work is. A serious candidate can share a redacted PR, walk through a private repo on screenshare, or show an architecture write-up without leaking a previous employer's IP.
Five questions beat a whiteboard interview
You do not need a coding test to learn whether someone can operate. You need questions where the shape of the answer is visible even if you cannot grade every technical detail.
1. "Walk me through the last bug you shipped to production." Senior engineers have scars and can describe them plainly: what broke, how they found it, what they changed, and what guardrail they added afterward. Frauds get vague or blame the rest of the team.
2. "What would you not touch in our stack right now?" This filters out rewriters. A senior engineer knows that the fastest way to destroy a young product is to replace working parts before understanding why they exist.
3. "Our app uses Supabase and Postgres. What happens if 1,000 people sign up in one hour?" You are listening for concepts: connection limits, RLS policy cost, rate limits, indexes, background jobs, and cold starts. They do not need your exact numbers on the call; they need to have seen this movie before.
4. "Show me a PR you wrote with Cursor or Claude Code assistance." In 2026, AI use is not the differentiator. Taste is. Good engineers can explain what they accepted, what they rejected, and what rules they use to keep generated code from drifting the codebase.
5. "Explain database indexes to me in 90 seconds." Your first engineer will teach you enough to make better product decisions. If they condescend, hand-wave, or get annoyed by follow-up questions, that is how the next six months will feel.
A paid trial is cheaper than a confident mistake
The strongest hiring processes do not end with a vibe check. Linear, Automattic, PostHog, and other serious software teams use paid work simulations because real work exposes the gaps interviews hide. Their exact formats differ, but the pattern is the same: pay the candidate, use real or realistic work, and judge communication as much as output.
For a first engineer, the trial should be short, paid, and real. Our recommended budget is 3 to 5 working days, a $3K to $8K flat fee for a senior contractor, and one ticket from your actual repo. Give them repo access, staging access, and one Slack channel. The output is a PR, a written one-page reflection, and a 30-minute walkthrough.
The ticket should be useful even if you do not hire them. Pick something with clear acceptance criteria: add a Stripe billing state fix, harden a Supabase policy, move one OpenAI call behind a server endpoint, or add observability around a fragile flow. Do not give them a toy problem. You are hiring someone to protect a live product, not solve riddles.
What matters is how they work. Do they ask one good question before coding? Do they write a PR description that explains why the change exists? Do they show tests or at least a manual verification path? Do they name the risk they did not fix?
The math is simple. In our model, a paid trial costs about $5K. A wrong first engineering hire can reach six figures quickly. At the high end, it can look like a $250K mistake once you count six months of salary, recruiter time, delayed roadmap, production debt, and the second engineer you hire to unwind the first one's work.
Eleven red flags are enough to stop the process
Do not soften these because the candidate is charming. The charm is part of the risk.
- They recommend a rewrite before reading the code.
- They quote a fixed number before seeing the repo.
- They refuse a paid trial because they are "too senior."
- They will not show prior work in any form.
- They promise business outcomes like "100K users" instead of engineering outcomes.
- They estimate unfamiliar work in days when it clearly has week-level unknowns.
- They speak in absolutes: "Postgres cannot handle that," "you need Kubernetes," "AI does it all now."
- They never ask who your customers are or what breaks first.
- They push for a monthly retainer on day one with no scoped deliverable.
- They have no questions for you at the end of the call.
- They will not sign a basic NDA and IP assignment before touching the repo.
One red flag can be context. Three is a pattern. If the pattern appears before money changes hands, believe it.
Green flags are just as specific
The right engineer does not sound magical. They sound careful, curious, and slightly allergic to premature certainty.
They ask to see the code before quoting. They ask who your customers are and what they complain about. They ask about monitoring, alerts, backups, and how you recover when Stripe or Supabase behaves badly.
They estimate in ranges with assumptions: "2 to 4 weeks if auth is already clean, 6+ if we need to migrate user state." They tell you what they would leave alone. They send a written follow-up that summarizes what they heard, what they would do first, and what they would not do yet.
The strongest signal is teaching. If they can make you understand why one RLS policy matters, why direct browser-to-database access is risky, or why a migration needs a rollback plan, they are reducing your dependence on them instead of increasing it.
The first engineer is an ownership decision
Your first engineer is not a pair of hands. They are the person who decides whether your Lovable or Bolt app becomes a production codebase or a more expensive pile of prompts. That is why the hiring process has to test ownership, not performance.
At appssemble, our engineering work starts the same way: read the code, name the risks, ship a contained fix, and only then talk about the larger roadmap. We do not sell hours or headcount. We take responsibility for the product surface we touch.
If you are about to hire your first senior engineer and the repo already has traction, run the reverse review and paid trial before you commit. In our typical budget model, the trial is a roughly $5K decision. The wrong hire can become a six-figure cleanup.
Book a call if you want us to review the codebase, shape the trial ticket, or take ownership of the first production hardening pass.