The Founding Engineer Hire: How Agencies Poach, Vet, and Keep Their First Product Engineer

Every agency that tries to spin out a product eventually hits the same wall: the client work funds the dream, but nobody on the client-work roster actually wants to build the dream. So you go hire a founding product engineer — and that hire is where most agency-to-product transitions quietly die.

We've watched this play out across our own attempts and dozens of peers'. The pattern is consistent enough to write down.

Why the Founding Engineer Hire Breaks Different Rules

A senior engineer on client work is optimising for a specific game: predictable scope, defined acceptance criteria, someone else owning the roadmap. A founding product engineer is playing the opposite game. They own ambiguity. They kill features you spent a weekend prototyping. They tell the founder — you — that the thing you promised a prospect last Tuesday is not going in the MVP.

If you hire the best client-work engineer you know and drop them into that role, you will get a beautifully engineered product that solves the wrong problem. We've done it. It's expensive.

The founding engineer role has three non-negotiable traits:

• Product instinct. They argue about the user, not the stack.
• Comfort deleting code. Including their own, from last week.
• Willingness to be lonely. No team to lean on. No senior above them. You are not senior to them on product engineering — you're the client.

Seniority on paper is nearly irrelevant. We've seen five-year engineers outperform fifteen-year architects in this seat, purely because the five-year had shipped two side projects to real users and the architect had never watched someone bounce off their onboarding.

Where to Actually Find Them

Job boards are the wrong channel. You're looking for someone who has already demonstrated the traits above, which means they leave a trail.

The three trails worth following

1. Public side projects with real users. Not GitHub stars — actual users. A Chrome extension with 400 weekly actives tells you more than a 4k-star repo nobody uses.
2. Technical writing that argues a position. Blogs that take a stance ("why we dropped Kafka", "our migration off Firebase") signal someone who forms opinions and defends them. That's the muscle you need.
3. Former founders who bounced. Engineers who started something, ran out of money or co-founder patience, and went back to a job. They know what shipping to strangers feels like and they usually miss it.

Inside your agency, the candidate pool is smaller than you think. Look for the person who keeps pitching internal tools, complains about your ticketing system, and ships weekend hacks. That's your shortlist. If nobody on staff fits, don't force it — hire externally and protect them from client work.

The Vetting Loop That Actually Works

Whiteboard interviews are useless here. You're not hiring for algorithmic depth, you're hiring for shipping judgement. Our loop, refined painfully over several hires:

Step 1: The teardown conversation (60 minutes)

Send them your product's current state — Figma, staging URL, or a written PRD if you're pre-build. Ask them to come back with what they'd cut, what they'd sequence differently, and what they think is dangerous.

Red flag: they praise everything or ask for more requirements before forming an opinion.

Green flag: they arrive with a shorter roadmap than yours and can defend the cuts.

Step 2: A paid build (3 – 5 days)

Not a take-home puzzle. A real, small, self-contained slice of the product. Pay a fair day rate. We've written before about structured paid trials for senior engineers, and the same shape applies — but here you're grading for product decisions inside the code, not just code quality.

What we look at, in order:

• Did they ask the right clarifying questions, or did they just start building?
• Did they scope down when they hit friction, or bulldoze through?
• Is the code boring in a good way? Founding engineers who over-engineer early kill velocity for a year.
• Did they ship something a user could touch?

Grading rubric we actually use:

  Scope discipline .......... 30%
  Product judgement ......... 25%
  Code clarity .............. 20%
  Communication cadence ..... 15%
  Curiosity about the user .. 10%

Stack expertise: 0%. We can teach the stack.

Step 3: The founder-fit dinner

Unfashionable but essential. You will fight with this person. You need to know how they fight before you're both under revenue pressure. If they can't disagree with you over dinner, they won't disagree with you when it matters.

Compensation Without Lying to Anyone

This is where agencies routinely blow the hire. You cannot pay a founding product engineer their agency market rate and also give them meaningful equity and also expect them to accept startup risk. Pick two, and be honest about which two.

Three structures we've seen work:

The "protected salary" model

Market-rate cash, funded by agency revenue, plus a smaller equity slice (0.5% – 2%) with a standard four-year vest. This works when the product is still an experiment and you don't want them betting their mortgage on it. Downside: they behave more like an employee than a founder, because they are one.

The "co-founder-lite" model

60 – 75% of market cash, meaningful equity (3% – 8%), and a written agreement that they get first refusal on the CTO title if the product spins out as a separate entity. This is our preferred structure when the person genuinely has founder energy but doesn't want to start from zero.

The "convert on milestone" model

Start them on a contract or full salary, and convert to a larger equity position when the product hits a defined milestone (first paying customer, ARR threshold, spinout event). Clean, unambiguous, and it aligns the risk-taking with the reward. Get a lawyer to paper this properly — handshake versions have ended friendships.

Whatever you pick, write it down. In an email at minimum, in a proper agreement ideally. The number of agency-to-product transitions that have imploded over verbal equity promises is genuinely tragic.

The First 90 Days: Protect Them From the Agency

Here is the failure mode we see most often. You hire the founding engineer. Two weeks in, a client project catches fire. You pull them in "just for a sprint". Three months later they're 60% on client work, the product hasn't moved, and they're updating their CV.

Rules we now hold as non-negotiable:

• Zero billable hours in the first 90 days. None. Not "a quick call". Not "just architecture review".
• Separate Slack workspace or channel structure. They should not see the firefighting.
• Their own weekly review with you, not the delivery lead. Product cadence is not delivery cadence.
• A written charter. One page. What the product is, who it's for, what's out of scope this quarter. Signed by both of you.

If you can't afford to protect them for 90 days, you can't afford to hire them yet. Wait, stack another two months of agency margin, and try again. This is one of the hardest lessons in the agency-to-product transition, and it's almost always a cash-flow problem masquerading as a discipline problem.

Signs You Hired the Wrong Person (and What to Do)

Six to eight weeks in, you'll know. Look for:

• They ask you what to build next, every week. Founding engineers propose; they don't wait.
• The codebase is beautiful but there's nothing users can click.
• They're uncomfortable talking to customers directly.
• They keep drifting toward client work because it's "more concrete".

None of these mean the person is bad. They mean they're a strong senior engineer, not a founding one. The kindest thing is to have the conversation early, offer them a senior role on the agency side if they want it, and restart the search. Dragging it out for six months to avoid an awkward week costs everyone more.

Where We'd Start

If you're an agency owner reading this on a Sunday because you're about to post a job ad on Monday: don't post the ad yet. Instead, this week, list the five engineers in your extended network who have shipped a side project to real users in the last two years. Message them personally. Ask what they're working on and what they'd want their next thing to look like. Two of the five will be curious. One of those two is probably your hire.

The founding engineer search is a sourcing problem disguised as a hiring problem. Solve the sourcing, and the rest of the loop we've described gets a lot easier.