June 20, 2026

Pair-build mode: how we work with vibe coders without taking over

Half-built side projects don't need a rescue team. They need a senior engineer on the other end of a Slack DM. Here's how we actually run pair-build engagements.

KEY TAKEAWAYS

↳Pair-build keeps the founder as the owner of record. We commit to their repo, on their branch, with their conventions.
↳We scope by the bug or the feature, not by the month. A typical session runs 2 to 8 hours and ends with a merged PR.
↳Vibe-coded codebases usually fail at the seams: auth, payments, background jobs, and anything that crosses a network.
↳We document decisions inside the repo (ADRs, README updates) so the founder can keep shipping after we leave.

Most of the projects that land in our inbox are 70% done. The landing page works, the core flow demos well, Stripe is wired up in test mode, and then something breaks the moment a real user touches it. Webhooks fire twice. The Supabase RLS policy is wrong. The Cursor-generated auth flow has a redirect loop on mobile Safari.

The founder has been staring at it for three weeks. They don’t want a rewrite. They want someone to sit next to them for an afternoon and unstick the thing.

That’s pair-build mode. It’s the engagement we run more than any other, and it’s the one I want to describe honestly, because the alternative (“hand it over, we’ll take it from here”) is what most agencies sell and it’s wrong for this kind of work.

What pair-build actually is

Pair-build is a scoped session where one of us joins the founder’s repo, on their branch strategy, with their tooling, and we ship one thing together. Usually it’s a bug, a feature, or a deploy that’s been stuck.

The rules we hold ourselves to:

We commit to their repo. Not a fork. Not a “clean rewrite branch.” Their main, their conventions.
We open a PR they review. Even if they’re going to merge it 90 seconds later.
We leave comments in the code where a decision wasn’t obvious.
We don’t introduce a new framework, new ORM, or new deploy target unless the founder asks. If they shipped on Astro and Cloudflare Workers, we ship on Astro and Cloudflare Workers.

The last one is the one that gets violated by every agency I’ve worked alongside. Someone shows up, sees a Next.js app with a slightly weird folder structure, and three days later there’s a Turborepo monorepo with four packages and a contributor guide. The founder now owns a codebase they can’t navigate. That’s not help. That’s a hostage situation.

Why vibe-coded projects break in predictable places

If you’ve shipped anything with Cursor or Claude Code, you know the model is great at the middle of a feature and bad at the edges. The edges are where two systems meet.

The ones I’ve debugged most often in the last six months:

Stripe webhooks. The signature verification works locally with the CLI and silently fails in production because the raw body got parsed by a middleware. I’ve fixed this exact bug in four different codebases this year.
Supabase RLS. The policies look right, the queries return data in the SQL editor, and then the client gets an empty array because the JWT isn’t being attached. Usually a missing await on the auth helper.
Background jobs. Someone asked the model for a cron, got a setInterval inside an API route, and now the job runs zero or seven times depending on how many serverless instances are warm.
Email deliverability. Resend is configured, the API returns 200, and the email is in the spam folder because SPF and DKIM aren’t set on the sending domain. The model doesn’t know this because it’s a DNS problem, not a code problem.
Mobile Safari auth redirects. Third-party cookies, ITP, the whole mess.

None of these are hard. They’re just outside the loop the model can see. A senior engineer recognizes them in about 90 seconds. That’s most of what we’re selling: pattern recognition on the parts the LLM can’t reach.

How a session actually runs

A typical pair-build looks like this:

10:00  Kickoff call, 15 min. What's broken, what we're shipping today.
10:15  I clone the repo, get it running locally. Founder stays on the call
       or drops off, their choice.
10:45  I push a branch, open a draft PR with my plan as the description.
11:00  We work. Founder is in Cursor on their machine, I'm in mine.
       We share a Slack channel and a Tuple or Zoom session if needed.
13:00  PR is ready. Founder reviews, we merge.
13:30  Deploy is green. I write a short Loom walking through what
       changed and why.

That’s it. Four hours, one merged PR, one Loom. No retainer, no “discovery phase,” no Notion workspace with 14 pages.

For bigger pieces (say, building an AI support agent into an existing app) we’ll run two or three of these back to back across a week. Same shape, just more PRs.

What we write down so the founder isn’t stuck after

The failure mode of any consulting engagement is that the consultant leaves and the codebase becomes unmaintainable for the person who stays. We try hard to avoid this.

Three things we always do:

ADRs for non-obvious choices. A short markdown file in /docs/adr/ explaining why we picked, say, Cloudflare Turnstile over hCaptcha for a specific form. Two paragraphs, not an essay.
README updates. If we added an env var, it goes in the README with an example value. If we changed the deploy command, same.
Inline comments where the model will get confused next time. Because the founder is going to ask Cursor to modify this code in three weeks, and the comment is for that conversation as much as for a human reader.

This sounds boring. It is boring. It’s also the difference between a codebase the founder can keep shipping on and one they can’t.

What we won’t do

We won’t take over the project. If you want someone to own the roadmap and the deploys and the on-call, that’s a different engagement, and honestly for most early-stage products it’s the wrong one. You should be the person who knows the code best. We’re there to unblock, not to replace.

We also won’t rewrite working code because it’s not how we’d have written it. If your route handler is 300 lines and it works, it stays 300 lines. We’ll refactor the part we’re touching. The rest is your call.

And we won’t ship something we wouldn’t put our name on. If the right move is “don’t build this feature, your real problem is onboarding,” we’ll say that on the kickoff call and refund the session. Has happened twice this year.

When pair-build is the wrong fit

If you’ve never deployed the app, pair-build is too late in the process. You need someone to set up the project, not unstick it. If you’re trying to hand the whole thing off and stop coding, you want a full build engagement, not this.

And if the codebase is genuinely beyond saving (I’ve seen maybe three of these, all involving a model that decided to invent its own ORM), we’ll tell you. Rewriting four files is fine. Rewriting forty is a different conversation.

If any of this sounds like the shape of what you need, tell us what’s stuck and we’ll book a session this week.

FREQUENTLY ASKED

Common questions

▸How much does a pair-build session cost?

We price by the session, not the hour. A standard 4-hour session is a flat fee that we quote on the kickoff call once we see the repo. If we can't ship something useful in that window, you don't pay. We'd rather refund than drag out an engagement that isn't working.

▸Do I need to be on the call the whole time?

No. We need you for the first 15 minutes to align on what we're shipping, and for the PR review at the end. The middle is heads-down work. Most founders drop off, do their own thing, and come back when the PR is ready. Some prefer to stay in a shared Slack channel and watch the commits land.

▸What stack do you work in?

Whatever you're already on. We've shipped pair-builds in Next.js, Astro, SvelteKit, Remix, plain Node, FastAPI, and a Rails app once. Deploy targets we've touched recently: Vercel, Cloudflare Workers, Hetzner, Fly, Railway, Supabase, Firebase. We adapt to your repo, not the other way around.

▸Can you help with the AI agent parts specifically?

Yes, that's most of what we do. If you've prototyped an agent in Cursor and it works on the happy path but falls over on tool calls, streaming, retries, or eval, that's a normal pair-build session for us. We'll wire up proper error handling, add a small eval harness, and leave you with something you can actually monitor in production.

▸What if we need ongoing help after the session?

We'll book another session when you're stuck again. Some founders run one a month, some run three in a week and then nothing for six months. There's no retainer and no minimum. If you want continuous involvement, we can talk about a fractional arrangement, but that's a separate conversation we'd only suggest if it's clearly the right fit.

5/20/2026