How to manage a remote developer when you can't code
How to manage a remote developer when you can't code
Manage a remote developer when you can't code by judging progress through working demos, not status updates. Set a daily 5-minute Loom standup, a weekly Friday retro, and use Linear plus GitHub as your visibility layer. When the engineer shows a PR or a Loom, paste it into Claude or ChatGPT for a plain-English translation. The trick is replacing "trust me, I'm working on it" with "here is the thing working."
If you have ever sat in a Zoom with a developer, nodded at words like "refactor" and "schema migration," and walked away with no idea whether the week went well, this post is for you. Non-technical founders lose more money to bad management than to bad code. The fix is a small set of rituals that any founder can run, plus one AI translator trick that turns engineering jargon into something you can actually act on.
Why "I'm working on it" is the wrong unit of progress
Most non-technical founders accept verbal status as proof of work. That is the single biggest mistake.
"I'm working on the auth system" can mean four hours of Stripe webhook debugging or four hours of arguing with Clerk's docs in a browser tab next to Twitter. You cannot tell the difference. The developer might not be able to tell the difference either.
The fix is to make the demo the unit. If you cannot click a button and see the feature work, the feature is not done. If the engineer cannot show you a Loom of the thing working, treat the week as if nothing shipped. This sounds harsh. It is the only way to keep a remote team honest when you are not the one reading the code.
This works because shipping a demo is irreducible. You can fake a status update. You cannot fake a 90-second screen recording of the new flow.
The 3 rituals that replace technical oversight
You need exactly three recurring events. Skip any of them and you lose signal within two weeks.
Daily 5-minute Loom standup
Every weekday morning, the engineer records a 5-minute Loom covering three things:
- What I shipped yesterday (with a demo if visual, a PR link if not)
- What I am shipping today
- What is blocking me
You watch it at 2x speed on your phone over coffee. Total time: under three minutes for a 5-engineer team. Loom is free for under 25 videos a month, which covers a solo engineer with room to spare. For teams of 2+, the $12.50/seat Business tier is worth it for the transcript search.
Why Loom instead of a Slack standup? Because text standups become "still working on the auth refactor" three days in a row, and you have no way to verify that anything happened. A Loom forces the engineer to point at something concrete on screen.
Weekly Friday retro
Thirty minutes on Friday afternoon. Three questions:
- What did we ship this week? (List of merged PRs with a one-line user-facing summary.)
- What slipped, and why?
- What is the plan for next week?
The "why it slipped" question is the most important one you will ever ask a developer. Good engineers will tell you the truth: "I underestimated the Stripe webhook complexity by 2 days." Bad engineers will say "we ran into some unexpected issues" three weeks in a row. The pattern shows up fast.
Record the retro. Watch it back before the next one. You will catch contradictions and accountability gaps that you missed live.
The 11pm sanity check
Once a week, on a random night, open Linear and GitHub yourself. Don't ask the engineer. Just look. Count the merged PRs, scan the Linear board, see what moved from "in progress" to "done." If the picture matches what the engineer told you on Friday, you are fine. If not, you have a conversation on Monday morning. This takes 10 minutes and catches drift before it becomes a 4-week problem.
How to read a PR without knowing how to read code
You don't need to understand the code. You need to understand the shape of the work. That is something a non-technical founder can absolutely learn.
Open any PR (pull request) on GitHub. Look at four things:
| Signal | What to look for | Red flag |
|---|---|---|
| Size | Lines changed (top of PR) | Single PR over 1,000 lines without a great reason |
| Cadence | How often PRs merge | Zero merged PRs for a week with no good explanation |
| Description | Plain-English summary of what changed | Blank description or just "fixes" |
| Tests | Whether test files appear in the changed files | New feature with zero test coverage added |
A healthy mid-level engineer ships 3-8 PRs per week, mostly under 400 lines each. A single 2,000-line PR every two weeks is usually a sign someone is working in isolation and stitching together a Frankenstein at the end. A pattern of 12 tiny PRs per week (50 lines each) is fine if features are landing, but worrying if the Linear board isn't moving.
You do not need to read a single line of code to spot these patterns. You just need to look at the GitHub repo's "Pulses" tab (Insights → Pulse) once a week. It gives you a one-page summary: PRs opened, PRs merged, issues closed, contributors. If a week shows 0 merged PRs and the engineer told you on Friday that "we made great progress," you have a problem.
The AI translator trick
This is the single highest-impact move a non-technical founder can make in 2026.
When the engineer sends you a PR you don't understand, copy the diff (the changed code) and paste it into Claude or ChatGPT with this prompt:
"Explain this PR in plain English for a non-technical founder. Tell me: what user-visible thing changed, what could break, and what one question I should ask the engineer."
The output is usually a 200-word summary that turns "Refactored AuthProvider to use server-side session validation with httpOnly cookies" into "We moved the login security from the browser to the server. Users won't notice. This makes the app harder to hack, but if it breaks, nobody can log in. Ask the engineer: did you test the existing login flow end-to-end after this change?"
You can do the same with Loom transcripts, Linear comments, and Slack messages from the engineer. Paste, ask for a translation, ask for the one follow-up question. You now sound like a CTO because you have one in your pocket.
Cursor and Claude Code work the same way if you want to go a step further: connect your repo and ask the AI questions like "did anyone change the billing logic in the last two weeks?" The AI will read the commit history and tell you. This is a real superpower for a non-technical founder. We covered the broader hiring side of this in our guide on how to find a technical advisor for your startup, which complements the management side covered here.
Red flags a non-coder can catch
You don't need to be technical to spot a developer who is drifting. The signals are behavioral, not technical.
- PR descriptions get vaguer over time. Week 1: "Adds Stripe webhook handler for invoice.paid events, with retry logic and idempotency keys." Week 4: "Webhook stuff." This is a sign of cognitive load or disengagement.
- The same blocker shows up in three standups. "Still blocked on the API schema" on Monday, Tuesday, and Wednesday means the engineer either hasn't actually started working on it or is stuck and won't say so.
- Demos stop being live. Week 1 demos show the feature working in a real browser. Week 4 demos are slides with bullet points. The work has stopped, but the meeting hasn't.
- Estimates double every week. "Two days for this feature" becomes "actually, four days" becomes "we hit some complexity, maybe a week." This is usually a scoping issue, not a competence issue, but it requires intervention.
- PRs stop merging into main. A pile-up of open PRs that nobody reviews or merges means the engineer is working but not shipping. If you don't have a second engineer, you should be the one approving and merging. (You don't read the code; you just click "merge" once the engineer confirms tests pass and the demo works.)
You will catch all of these inside 30 minutes a week if the three rituals are in place. The cost of not catching them is usually a month of burn before you notice. The math doesn't favor skipping the rituals. The same logic applies to scope: if you're not sure where features are bloating, our piece on how to handle scope creep as a founder walks through the contracting side.
Comparison: how to set up oversight for different team sizes
The right management stack depends on team size and budget. Here is what we recommend.
| Setup | Stack | Cost / month | Best for |
|---|---|---|---|
| Solo engineer | Loom Free + GitHub Free + Linear Free | $0 | Pre-revenue, single contractor |
| Solo engineer (paid) | Loom Business + Linear Standard + GitHub Team | ~$30 | First 6 months post-launch |
| 2-4 engineers | Loom Business + Linear Standard + GitHub Team + Slack | ~$120 | Seed-stage team |
| DIY no oversight | Nothing | $0 | Burning $4-12k/month with zero signal. Don't. |
The "DIY no oversight" row is the most common setup we see at Cadence onboarding. Founders pay $8k/month for a senior contractor, have a weekly Zoom, and have no idea what shipped until they get a Stripe Atlas tax form 11 months later. The $30/month tooling spend pays for itself the first time it stops you from extending a non-performing engineer for an extra week.
When to book a managed engineer instead
The rituals above work. They also assume you have the bandwidth to run them. A solo founder doing sales, support, and product can lose two hours a day on management overhead if they aren't careful.
If you'd rather skip the management layer, an on-demand model can carry some of that for you. Cadence is one option here. We pre-vet every engineer on a voice interview that covers AI-native fluency (Cursor, Claude Code, Copilot) and async communication, so the management overhead per engineer drops significantly. Daily ratings give you a structured way to flag concerns without firing anyone awkwardly; if a rating drops below 3 stars two days in a row, we auto-source a replacement. Weekly billing means a non-performing engineer costs you at most 7 days, not a 60-day notice period.
Pricing is tier-based. Junior ($500/week) for cleanup and integration work. Mid ($1,000/week) for end-to-end feature shipping. Senior ($1,500/week) for architecture and complex refactors. Lead ($2,000/week) for fractional CTO scope. The 48-hour free trial means you can test-drive the rituals before you commit a dollar.
If you're earlier than that, our guide to Fractional CTO vs full-time CTO covers the strategic-judgment side, which complements the day-to-day-management piece covered here. And if you're choosing tools alongside the engineer, our take on how to choose a CMS for your startup site helps non-technical founders pick stacks that match their own bandwidth.
What to do this week
If you're managing a developer right now without these rituals in place, here's the concrete next step. Pick the smallest version you'll actually do:
- Send the engineer one Slack message tonight: "Starting tomorrow, can you record a 5-minute Loom each morning covering yesterday, today, and blockers? It replaces our existing standup."
- Block 30 minutes on Friday at 4pm and call it "Weekly Retro." Send the calendar invite.
- Open your GitHub repo's Insights → Pulse tab for the last 7 days. Look at the numbers. Sit with them.
You have just set up 80% of the management discipline of a senior CTO in under 10 minutes. The other 20% is consistency over months. If you want to skip the setup entirely and get an engineer who arrives with these rituals already in place, start the Cadence founder onboarding; it takes 2 minutes and the first 48 hours are free.
If you'd rather not run the management layer yourself, every engineer on Cadence ships under these rituals by default, with daily ratings and weekly retros built into the platform. Book a 48-hour free trial and the first two days cost nothing.
FAQ
How do I know if my remote developer is actually working?
Judge by output, not hours. Count merged PRs per week, watch the daily Loom, and check the Linear board on a random night. A mid-level engineer should ship 3-8 PRs per week, mostly under 400 lines each. If the number is zero for more than a week without a clear architectural reason, ask why. Don't track hours; track shipped demos.
What if I don't understand the technical work my developer describes?
Use AI as a translator. Paste the PR diff, Loom transcript, or Slack message into Claude or ChatGPT and ask: "Explain in plain English what changed, what could break, and what one question I should ask." This takes 30 seconds and gives you the vocabulary to ask intelligent follow-up questions. You don't need to learn to code; you need to learn to interrogate.
How often should I have meetings with a remote developer?
One 5-minute async Loom standup per weekday, one 30-minute Friday retro per week, and that's it. Total synchronous time: 30 minutes per week. More than that creates context-switching overhead and signals you don't trust the engineer's judgment. If you need more meetings to feel comfortable, that's usually a sign you hired the wrong person.
Should I ask my developer to share their screen while they work?
No. Screen-sharing as oversight is a sign of broken trust and it kills productivity. If you don't trust an engineer enough to leave them alone for 6 hours, replace them. The whole point of the demo-based rituals is to make trust verifiable through output, not surveillance through input.
What's the cheapest way to set up developer management as a non-technical founder?
Loom Free, GitHub Free, Linear Free. Total cost: $0/month for a single engineer. Add the AI translator (Claude or ChatGPT, $20/month) and you have a management stack a YC partner would approve of for under $25/month. The expensive tools come later; the rituals are what matter.