How to manage multiple client projects as a dev agency
How to manage multiple client projects as a dev agency
Managing multiple client projects as a dev agency comes down to four operational decisions: how you allocate engineers (dedicated pods vs pooled), how you protect focus time (4-hour blocks, capped switches), how you measure capacity (target 70% billable, treat 80%+ as burnout), and how you fire bad clients before they sink the others. Everything else (Slack discipline, intake forms, the right PM tool) is downstream of those four.
If you run a 6 to 20 person shop, this is the playbook we see working in 2026. Not the generic "use Asana and have weekly syncs" advice. The specific numbers, rituals, and kill criteria.
The math that decides everything: context-switching tax
Researchers at UC Irvine and Microsoft have measured what happens when a knowledge worker switches between unrelated tasks. The number that keeps showing up: roughly 20 to 25 minutes of recovery time per interruption to get back to peak focus, and a measurable productivity drop of around 20% across a day where switches are frequent.
For a dev agency, every client is a context. Different repo. Different stack. Different domain. Different Slack channel. Different relationship.
A senior engineer juggling four clients in a single day is not delivering 100% of their capacity divided by four. They are delivering closer to 50%, with the rest absorbed by the cost of switching contexts. This is the single most under-priced cost in agency work.
Two practical implications:
- Cap context switches per day. A senior engineer should hit at most two clients per day. Ideally one. Never four.
- Schedule in 4-hour focus blocks, not hours. A 1-hour task on Client A's codebase is rarely a 1-hour task. It's 1 hour of work plus 25 minutes of ramp-up plus 15 minutes of post-task drift. Block bookings in halves of a day.
If you cannot run your shop on those two rules, you are over-booked or under-staffed. Both are fixable.
Allocation pattern: dedicated pods vs pooled engineers
Most agencies default to "whoever is free picks up the ticket." That's the pooled model. It looks efficient on a Gantt chart and feels disastrous in practice, because every ticket carries a full context-switching tax.
The alternative is dedicated pods: 1 to 3 engineers permanently assigned to a single client for the duration of the engagement. They own the codebase. They sit in the client's Slack. They speak the client's domain language by week 3.
Here is the trade-off, honestly:
| Allocation | When it works | When it breaks |
|---|---|---|
| Dedicated pods | Long retainers (6+ months), complex domains, codebases where ramp time is a tax | Short projects, spiky demand, when an engineer churns mid-engagement |
| Pooled engineers | Standardized stacks (Next.js + Supabase across all clients), short projects, well-documented systems | Anything custom, anything domain-heavy, senior architectural work |
| Hybrid (dedicated lead + pooled IC) | Most agencies, most of the time | Requires the dedicated lead to be genuinely senior |
The hybrid wins for most shops. One senior or lead per client is the dedicated context-holder. ICs (often mid-tier) get pulled in for feature work and rotated. The lead does code review, architectural decisions, and is the one person on the client's Slack with full memory of every decision since week one. Read more on the healthy utilization rate ranges by role before you set targets for your pods.
Capacity planning: the 70/80 rule
The single most useful number in agency operations is target billable utilization. Set it to 70% for engineers.
That means in a 40-hour week, you target 28 billable hours. The other 12 absorb meetings, code review, internal work, learning, and the unavoidable cost of being a human at a job. Push utilization above 80% and you start seeing the same pattern every time:
- Engineers stop reviewing each other's PRs carefully
- Documentation rots
- Engineers start working evenings to "catch up"
- The good ones quit within 6 months
We have seen agencies hit 90% utilization for a quarter and then lose three of their five senior engineers in the next six weeks. The math is not subtle. If you measure utilization weekly and one of your engineers crosses 80% for two weeks in a row, you have an over-booking problem, not a productivity win. For the mechanics of measuring this honestly without inflating numbers, our breakdown of how dev agencies should track time is worth the read.
The corollary: if your average utilization is below 60% across a quarter, you have a sales problem, not a delivery problem. Stop hiring. Go sell.
The tooling stack that actually works
Every agency has a tooling religion. Here is the honest comparison of what we see in the wild.
| Tool | Best for | Honest weakness |
|---|---|---|
| Productive.io | Mid-size agencies (10-30 people) wanting time, capacity, billing in one place | Heavy. Onboarding takes a quarter. |
| Float | Pure visual capacity planning across a team | Standalone. You'll still need a separate PM tool. |
| Forecast | AI-driven scheduling and resource forecasting | Pricing scales fast at 20+ seats. |
| ClickUp | Per-client task management with custom views | Easy to over-customize and end up with chaos. |
| Custom Notion + a time tracker | Sub-10-person shops who want to design their own system | Breaks at scale. Expect to migrate by the time you hit 15 people. |
There is no right answer. There is only a right commitment. Pick one. Use it for everything. Do not run "ClickUp for tasks plus Slack for status plus Sheets for capacity plus Harvest for time." Every tool you add is another place where the truth lives, and the truth has to live in exactly one place or it doesn't live anywhere.
The decision rule we give agency founders: if you have under 10 engineers, custom Notion plus a tracker is fine. From 10 to 30, Productive.io or Float plus ClickUp. Past 30, you probably need someone whose actual job is operations.
The Friday rollup ritual
This is the single highest-impact operational ritual we have seen at agencies that scale past 10 people without falling apart.
Every Friday at 4pm, every engineer posts a structured update in a single channel. Not a freeform status. A template:
- Client: name
- Shipped this week: bullet list, max 5
- Blocked or at risk: anything yellow or red
- Hours billed vs target: actual / 28
- Confidence in next week's plan: green / yellow / red
The agency owner reads all of them in 20 minutes Saturday morning. By Monday standup, they know which clients are healthy, which are about to blow up, and where to spend their week. Without this, you find out a project is on fire when the client emails on Tuesday afternoon.
The ritual has a second function. The act of writing the update forces the engineer to confront whether they are actually shipping. Engineers in trouble write vaguer Friday updates two weeks before things visibly break. The pattern is reliable enough to act on.
Escalation chains: who calls the founder when client A is on fire
Agencies that scale beyond the founder's bandwidth have a documented escalation chain for every client. Most agencies do not have this. Then a client pings the founder at 9pm on a Sunday and gets a response, and now every escalation routes through the founder forever.
The chain we recommend:
- L1, the dedicated engineer. Handles 90% of client questions. Has authority to commit to scope changes under 4 hours.
- L2, the engagement lead (typically a senior or lead from your shop). Handles trade-off conversations, scope renegotiation, and anything technical that the dedicated engineer cannot answer.
- L3, the founder. Handles only: contract disputes, churn risk, scope changes over 1 week of work, and the "we are about to fire you" conversation.
Write this down. Put it in the SOW. The first time a client tries to escalate past L1 by texting the founder directly, the founder routes them politely back to L2. Within two clients, the pattern locks in.
If you skip this, you become the bottleneck on every account by month nine. We have watched this play out at exactly the same growth point at three separate agencies in the last 18 months.
Kill criteria: when to fire a client
The single best margin lever we see at healthy agencies is firing the bottom 10% of clients every year.
Specific red flags that mean a client should be fired:
- Payment more than 30 days late twice in a year. Cash flow signal. They are also late with their staff and their landlord. You will not be the priority.
- Scope changes without written approval, more than twice. Process signal. They will dispute your invoice eventually.
- More than 5 hours per week of unpaid "quick questions" from the client lead. Your margin is being eaten in Slack DMs.
- NPS or qualitative rating from your engineers is consistently below 6. Your team will quit before they tell you why.
- Margin below 30% for two quarters running. Pricing signal. Either renegotiate or walk.
Codify these in a quarterly account review. Not every red flag means immediate fire. Two or more in the same quarter, and you should have a serious conversation about whether to renew, reprice, or walk away at the next contract break.
The reason most agencies do not do this: every client looks important when revenue is concentrated. The fix is to never let a single client cross 25% of revenue. That math should drive your sales targets more than your delivery capacity does.
The three-client minimum anti-pattern
This one is specific to agencies trying to stay "lean." The pattern: an agency owner believes that putting one engineer on three clients at once is more efficient than putting them on one or two. The reasoning is that no client gets stuck waiting if the engineer hits a blocker.
It is wrong. We have measured it.
An engineer on three concurrent clients delivers roughly 55-60% of the throughput of the same engineer on one or two. The context-switching tax compounds. By the third client, the engineer is operating from a stale mental model on at least two of them at any given moment. They make more architectural mistakes that have to be unwound later. They miss client communication windows because they are heads-down on a different repo.
The right shape: one engineer on one client (high focus, often retainer). Or one engineer on two clients (split half-days, never quarter-days). Three or more is a structural problem that cheap-feels-expensive.
If you find yourself running engineers across three or more clients, the diagnosis is usually that you have one client too many for your team size, and you should either fire a client (kill criteria above) or book a temporary engineer to absorb the spike. For practical pricing on those bench moves, our breakdown of dev agency pricing models covers the margin math on retainer vs hourly vs productized work.
Bench-on-demand: the structural alternative to over-hiring
Here is the move most agencies miss.
When demand is spiky (you have one big client kicking off and another wrapping in two months), the default reaction is to hire. A full-time hire takes 8 to 14 weeks to source, interview, sign, and ramp. By the time they ship their first PR, your spike is already over and you are paying $9k a month for someone you cannot keep busy.
The structural alternative is a bench you book on-demand. You keep your core dedicated team (the 60% of capacity you are confident in for the next 12 months). For the spiky 40%, you book engineers by the week against the actual project, then release them when the spike is done.
Cadence is one option here. Founders book engineers in 2 minutes, every engineer is AI-native by default (Cursor, Claude, Copilot fluency vetted in a voice interview before they unlock the platform), and pricing is locked at junior $500/week, mid $1,000/week, senior $1,500/week, lead $2,000/week. Weekly billing, replace any week, no notice period. There is also a 48-hour free trial.
For an agency, the math is straightforward. Book a senior at $1,500/week. Bill the client at $4,000-$6,000/week (your standard senior rate). The margin sits at 60-70% with no payroll commitment when the project ends. Stack three or four of these per quarter against client spikes and you have built a structurally more resilient agency than the one running on full-time hires.
The agency partner program at Cadence pays 10% recurring on referrals, which is the other underused move. If you have founder friends who are about to hire and you can't take the work, refer them. The 10% on a senior engagement adds up.
What to do this week
If you read this and only do one thing, do this: open a sheet, list every active client, and write down for each one (a) which engineer is the L1 owner, (b) the actual billable hours delivered last week, (c) any red flags from the kill-criteria list. The exercise takes 90 minutes. The signal is sharper than any dashboard you have ever bought.
Then this week, run a Friday rollup at 4pm with your team. The one in the template above. Do it for four weeks before changing the format. The pattern will become obvious by week three.
Run booked engineers under your agency brand. If you want to pilot the bench-on-demand model, Cadence's partner program lets agencies run booked engineers at the agency markup and earn 10% recurring on referrals. Weekly billing, 48-hour trial, replace any week.
FAQ
What's a healthy utilization rate for a dev agency?
70% billable for engineers is the target. Below 60% sustained means you have a sales problem. Above 80% sustained means you are about to lose your best people to burnout. Project managers and creatives can run a bit lower; technical leads a bit lower still because they are absorbing review and architectural load.
Should I hire engineers or book them on-demand?
Hire for the work you are confident exists for the next 12 months. Book on-demand for everything spiky. Most healthy agencies in 2026 run a 60/40 split: 60% dedicated full-time team against committed retainers, 40% booked weekly against project spikes.
How many clients can one engineer handle at once?
One client for full-focus retainer or complex work. Two clients for standardized work split into half-days. Three or more is a structural problem, not a productivity strategy. The context-switching tax kills throughput well before it shows up in time-tracking data.
What's the best PM tool for managing multiple clients?
The best tool is the one you commit to using for everything. Productive.io, Float, ClickUp, and a custom Notion build are all defensible choices depending on shop size. The wrong choice is running four tools because each does one thing slightly better.
When should I fire a client?
When two or more red flags hit in the same quarter: payments 30+ days late twice, repeated unwritten scope changes, more than 5 hours/week of unpaid Slack questions, engineer rating below 6, or margin below 30% for two consecutive quarters. Codify the criteria so the decision isn't emotional.