No, I Don't Scale. That's the Point.

People keep telling me to scale up. I run a boutique software agency and I do it intentionally small. I nod, say nothing, and don't change a thing. Not because I'm lazy. Because I tried.

Here's what happened.

What I found when I actually tried scaling

There was a stretch when we ran three projects simultaneously. Eight people. Not a huge agency, but not two engineers in a chat either. Revenue looked fine on paper. I thought: this is it. Scale is working.

Then I started counting.

Meetings. Daily status calls for each project. Onboarding time for someone I'd hired specifically to staff the third contract. Context switches — from Elasticsearch to a Bitrix integration, then back out to Next.js code review. By the end of a typical week, I had maybe four hours left for the things I'm actually good at: architectural decisions and direct client work.

One project shipped a production bug. Not critical — but the kind I'd have caught in code review if I'd been running two projects instead of three. In three-project mode, it reached the client first.

I didn't burn out. I just lost track of what we were building.

Three signals a project has left the boutique zone

After a few years, I've learned to notice the exact moment a new contract pushes us from manageable into overloaded.

First: I schedule a meeting to remember where we left off. If the project context doesn't hold in my head between sessions — the project is no longer boutique. It's not a discipline problem. It's not Jira. It's capacity.

Second: I bring in someone I didn't specifically choose for the work. When you hire someone "just to fill the slot" — solution quality doesn't go up, only coordination overhead does. In 2022 I hired a developer for a 28k-SKU catalog project. We spent two months getting the Elasticsearch setup right — and it worked because I was personally involved in every technical decision. Add one more parallel contract and I wouldn't have been.

Third: a client waits more than a day for a response with no good reason. If I can't reply within a business day, I'm not in control of that project.

My capacity policy

I have one rule now: no more than two active projects at once. Not three. Not "it depends on size." Two.

It's arithmetic. With two projects I have time to actually understand the problem before I answer. I run presales myself. I make architectural decisions without a three-step explanation chain.

A year ago, a potential client came to me with a headless migration project. Good budget, realistic timeline, reasonable client. The problem: I was already running two projects at peak load. I turned it down. The client found another contractor. Three months later they came back — same request, better terms — because the first contractor hadn't delivered.

That's not magic. Boutique reputation holds on predictability. Predictability holds on capacity.

What project #4 actually costs

Context switching costs more than people assume. I've measured it.

Moving from one codebase to another takes me about 40–60 minutes to genuinely re-enter the context. Not "I opened the file," but "I understand what's going on here and what's risky to touch." With two projects, that happens at most twice a day. With four projects, it's eight switches — and I spend half my working hours loading memory instead of working.

It's not about fatigue. Decisions made in the first twenty minutes after a context switch are worse. I see it in diffs: reviews I write an hour into context are meaningfully different from those I do ten minutes in.

One more number: when my team grew to eight people, revenue per person dropped. Not because people worked less. Because coordination time went up — and coordination time isn't billable.

Boutique isn't small. It's deep.

When someone says "you have a small agency," I hear "you don't have many people." That's the wrong unit.

Boutique means depth, not headcount. I know a client's codebase better than their in-house developer. If a client is about to make an architectural decision that'll create problems in six months, I tell them before they sign the next support contract with someone else.

That doesn't scale without losing something. I'm not trying to make it scale.

If a project needs more than a boutique can give — I say so directly. Sometimes that means the deal doesn't happen. More often it means the client knows exactly what they're getting.

I don't close tickets. I close risks. And the first risk is taking more than you can do well.