A failure mode I see often: a non-technical founder hires a developer to ship V1, then over the course of the project becomes the developer's de facto project manager. They're scheduling syncs, chasing status updates, breaking down tasks, fielding clarifying questions, mediating between integration vendors. The work eats 10 hours a week of the founder's time — time that should be spent talking to customers, fundraising, or selling.
By the time V1 ships, the founder has effectively run a project management role they didn't intend to take. The build is "successful" but the founder is exhausted and the business has stalled in everything else. This isn't the developer's fault, exactly. It's a management arrangement that emerged by default because nobody set up something better.
This article is about the management approach that prevents this drift. The principle is simple: hire developers who manage themselves, set up async rituals that don't require your moment-to-moment attention, and stay in the founder seat where you belong.
The principle: senior developers manage themselves
The most important hiring decision is upstream of management style. A senior developer doesn't need a project manager. They scope their own work, surface their own blockers, write their own status updates, and ship without being chased.
A junior developer needs significant project management. They wait for direction, don't surface blockers until forced, deliver on schedule but not on outcome.
If you're hiring a junior developer, you'll need to PM them. There's no management trick that compensates for inexperience. Either accept the PM workload or hire more senior. For most non-technical founders, the right choice is "hire more senior" — pay 2x the rate, have 1/5 the management overhead, ship faster overall.
This article assumes you've hired senior. If you haven't, the rest of the advice is partial — it'll help, but it won't fully save you.
The async rituals that work
Specific patterns that keep the relationship productive without scheduled syncs:
Ritual 1: end-of-day written summaries
The single highest-leverage practice. Every day the developer works, they write 3–5 sentences at end-of-day:
- What got done today
- What's in progress
- What's blocked or unclear
- What they're picking up tomorrow
You read it the next morning. Most days, you respond with "great, carry on." Some days, you have a question or a redirect. Either way, the conversation runs in the time you have, not in scheduled meetings.
Time cost for the developer: 3–5 minutes per day. Time cost for you: 1–2 minutes per day. Replaces: 30–60 minutes of weekly status meetings, plus the friction of "what are they working on right now?" anxiety.
Ritual 2: weekly priorities thread
Once a week, you start a thread (in Slack or your project management tool) listing the top 3 priorities for the next week. The developer responds with their plan and any clarifying questions.
This is your single weekly "real conversation." Five minutes of your time, five minutes of theirs. Done.
If the developer wants to add or change a priority, they say so in the thread. If you want to redirect mid-week (you'll want to occasionally), you say so in a new message and they adapt. The thread is the source of truth for "what are we building this week."
Ritual 3: Loom videos for hand-offs
Instead of a 30-minute meeting where you walk the developer through a new requirement, record a 3-minute Loom doing the walkthrough. They watch it during their day, respond async with questions, and start work without waiting for a synchronous slot.
This works for: new feature briefs, bug reports with reproduction steps, customer-feedback summaries, design hand-offs. Anything where you'd otherwise have a meeting to "show them" something.
The unintuitive benefit: Looms force you to be more concise than meetings would. You'll find your 30-minute meeting becomes a 3-minute Loom because you cut the verbal padding. Both sides save time.
Ritual 4: decision logs
Whenever an important decision gets made (in a meeting, in a Slack thread, in a call), the developer or founder writes a 1-paragraph decision log. Date, context, decision, why.
These logs live in a single doc — Notion, Confluence, a Google Doc. The whole project's decision history is in one place.
Why this matters: 6 weeks from now you or the developer will forget why you decided X. The log answers it instantly. Without the log, you have a 20-minute "what did we decide on this again?" conversation that drains both sides.
Ritual 5: monthly business context update
Once a month, you write 5–10 sentences of business context for the developer:
- Where customer revenue is at
- What's on fire externally
- What's coming up that affects the build
- Any strategic decisions that should influence their work
This is the bare minimum to keep the developer's work aligned with the business. Without it, they make decisions in a vacuum — perfectly correct technical decisions that miss the business priorities. Five minutes of your time once a month prevents weeks of wrong-direction work.
The meetings that don't work
Specific meeting types I'd cut from any developer engagement:
Daily standups
Adopted from agile methodology where they make sense for co-located teams. For founder + freelance developer, they're pure overhead. The end-of-day written summary covers the same information without the synchronous cost.
If you've inherited a daily standup expectation, kill it and replace with the written summary. Both sides save 30 minutes a day.
Weekly status meetings
If your weekly priorities thread is working, the status meeting is redundant. The developer's status is in their daily summaries; the priorities are in the thread. A meeting "to discuss" duplicates information that already exists in writing.
The exception: an actual conversation about something nuanced — a strategic call, a hard tradeoff, a customer relationship. These genuinely need synchronous time. But they should be agenda-driven, not "weekly check-in by default."
Sprint planning meetings
A relic of agency-style project management. For a single founder + single developer, sprint planning is overhead. Use the weekly priorities thread instead.
If the developer wants to do "sprint planning" because that's the methodology they're used to, fine — but it can be a 15-minute thread, not a 90-minute meeting.
Retrospectives
Designed for teams of 5+. For a 2-person founder/developer relationship, they're awkward. The "retrospective" is just an honest end-of-month conversation: what's working, what isn't, what we'd change.
Make it a 20-minute call once a month. Don't try to formalise it into Stop/Start/Continue or whatever the latest framework is.
What to delegate, what to keep
A founder/developer relationship requires some explicit decisions about who owns what. Without them, both sides default to "I guess I'll do it" or "I assumed they'd do it" — neither is healthy.
What the developer should own
- Architecture decisions within the agreed framework. They picked Laravel; they decide how to structure controllers.
- Implementation details. How to write the migration, what to name the variables, how to organise the test suite.
- Bug fixes within their normal cadence. They surface that there's a bug; they fix it; they tell you it's fixed.
- Code reviews of their own work. You don't review code line-by-line unless you specifically agreed to. They self-review and let you know when something's ready for QA.
- Deployment. They deploy to staging and production according to the agreed flow. You don't need to be in the loop on every deploy.
What you should own
- Business priorities. Which features ship in V1 vs V2. Which customer feedback to act on.
- Pricing and customer-facing copy. What things cost, how features are described publicly.
- Customer communication. Direct customer conversations stay with you, not delegated to the developer.
- Strategic decisions. Whether to add a major new direction, whether to drop a feature midway, whether to change pricing.
- Final QA sign-off. The developer says it's ready; you check that it does what you wanted before launch.
What's shared
- Roadmap. Both of you contribute. The developer surfaces technical realities; you decide what's worth building.
- Scope tradeoffs. When time runs short, both of you discuss what to cut. They have technical visibility; you have business visibility.
- Customer feedback synthesis. They might hear bug reports; you hear feature requests. You both contribute to what matters.
The founder-developer trust ladder
The relationship evolves over time. Specifically, it climbs a trust ladder as you both build evidence:
Rung 1: Strict accountability (week 1–4 of new relationship). You verify everything. Daily summaries, weekly meetings, code reviews of major changes, manual QA of every shipped feature. This sounds heavy because it is — and it's appropriate when you don't yet know if you can trust the developer's judgment.
Rung 2: Verify-then-trust (month 2–4). Daily summaries continue. Weekly meetings drop to bi-weekly. You QA shipped features but stop reviewing in-progress code. The developer is starting to make decisions independently and they're working out.
Rung 3: Trust by default (month 4+). Daily summaries continue but you skim them. Bi-weekly meetings become monthly. The developer makes most decisions without asking. You only intervene on truly strategic calls. The relationship feels collaborative rather than supervisory.
Rung 4: Long-term partner (year 1+). The developer knows the business almost as well as you do. They flag when you're about to make a mistake. They suggest features and improvements proactively. The relationship is more like co-founding the technical side than employing a contractor.
The ladder takes time. Don't try to skip rungs by trusting too early — that's how disasters happen. But don't stay on rung 1 forever; if the developer has earned trust over months, give it to them. The relationship can't grow if you keep the management style of the first month forever.
Red flags that mean you've drifted into PM mode
Self-diagnostic for whether you've quietly become the developer's project manager:
- You're spending more than 5 hours a week on developer-related work in normal weeks (not launch weeks).
- You're chasing the developer for status updates instead of receiving them.
- You're breaking work into smaller tasks for them rather than receiving their breakdown.
- You're scheduling more synchronous time with them than with customers.
- You're answering their clarifying questions throughout the day instead of in batches.
If two or more of these are true, you've drifted. The fix isn't to manage harder — it's to either (a) restructure the rituals so the developer manages themselves, or (b) acknowledge that you've hired junior and need to either accept the PM workload or upgrade to senior.
What to do next
The companion articles cover related decisions:
- Why Your Developer's Quote Will Be Wrong
- Hourly vs Fixed-Price vs Retainer
- Treating Offshore Hires as Colleagues vs. Vendors (the colleague-framing principle that underlies all of this)
If you'd like to talk about a specific developer relationship and how to structure it, the first call is free — see SaaS Startups, Bootstrappers, or Lead Steer Retainer.
---
Part of the Full-Stack Development for Solo Founders pillar guide.