Taking fewer projects isn't a capacity problem. It's a quality decision. Here's the reasoning behind keeping the client list short and what it actually means for the work.
Sahil Jadhav
Founder, Sero Studio
The most common question we get from potential clients after they learn we cap our active projects is some version of "why would you turn down work?" It's a fair question. The answer is not what most people expect.
We've seen it happen — in previous work, in agencies we've subcontracted for, in studios whose work we admire that suddenly starts slipping. The pattern is always the same. A few too many active projects. Response times slow. Code review gets rushed. QA is compressed. The first version of something that should have taken a day takes three because context-switching erodes focus faster than anyone budgets for.
The work doesn't get obviously worse. It gets quietly worse. The kind of worse that shows up in load times, in edge cases, in the documentation that was meant to get written after launch but never did.
We run a maximum of two active projects at a time. One in active development, one in discovery or design. That number isn't arbitrary. It's the maximum at which we can give every project the attention that justifies what we charge.
This means there are periods where we're not taking new work. We say so clearly on the site. We keep a short waitlist. Most serious clients — the ones we want to work with — plan ahead anyway.
When you're one of two active clients instead of one of twelve, the difference is tangible. Questions get answered the same day. Problems get solved properly instead of patched. The person who built it remembers what they built when something needs changing three weeks later.
That's not a luxury. It's the baseline for what professional software delivery should look like. We just built the business around actually doing it rather than saying it.
"The clients worth working with are the ones who appreciate that you're not working with everyone else at the same time."
The tradeoff is real. We grow more slowly than a studio that takes every project that comes in. We turn down work that we'd probably do fine on. Some clients choose a larger agency because they want the assurance that comes from headcount.
That's a legitimate choice. But if what you're looking for is a small team that treats your project like the only one on their board — because it effectively is — the cap is a feature, not a constraint.
More from the Studio
The most expensive conversation in software is the one you have three weeks into a build when someone says "I thought we were also doing X." Here's how a written scope document prevents that conversation from ever happening.
5 min read
Putting everything in a card is the fastest way to make a page feel like a grid of boxes. Here's how to use containment selectively to create visual rhythm rather than visual noise.
4 min read
Thoughts on building software, shipped occasionally.