Saying no to work we could probably pull off
A founder approached us last month with a marketplace idea: vendor onboarding, escrow payments, real-time inventory sync, a React Native app, and an admin dashboard. The MVP spec was twelve pages. He wanted it in eight weeks.
We turned it down. Not because we couldn't build pieces of it — we've shipped every one of those components separately — but because the shape of the project was wrong for a team our size.
A three-person workshop has a specific stress profile. Two developers and one project lead can hold roughly two active builds in the air at any time, plus maintenance on four or five shipped projects. That's the actual limit, not a theoretical one. We've tested it.
What fits
Work that fits our capacity tends to share a few traits. The scope is bounded by a specific pain point, not a platform vision. The client has a technical person on their side who can make decisions quickly, or is willing to defer to our judgment on the small stuff. The deployment target is something we already have infrastructure for — a Django app on EC2, a Next.js front end on Vercel, a Postgres-backed API on RDS.
A recent example: a manufacturing client needed a quality-tracking dashboard that pulled defect data off their existing Oracle DB and surfaced it for shop-floor supervisors. Two tables, one API, one React front end, role-based access. We shipped it in three weeks and we're still maintaining it.
That's the kind of work where being small is an advantage. No procurement overhead, no architecture review board, no two-week sprint planning ceremony. A client talks to us on Monday, we're in their codebase by Tuesday.
What doesn't
Projects that don't fit usually fail on one of three axes.
The first is concurrent complexity: anything requiring sustained work across three or more subsystems at once. A marketplace with payments, messaging, and real-time inventory is three projects wearing a trench coat. Each subsystem needs its own testing strategy, its own failure modes, its own monitoring. We can't parallelize that across two developers without one of them becoming a bottleneck on the other.
The second is unclear ownership on the client side. If there's no one authorized to answer a Slack message when we hit an ambiguity, we burn days waiting. A larger agency can absorb that idle time across multiple projects. We can't — the idle developer is half our capacity.
The third is maintenance commitment beyond what we can responsibly hold. We tell clients we stay on after launch, and we mean it. But if a project generates enough tickets to need a dedicated person, it's not our project anymore — it's a team that happens to be understaffed.
How we decide
The conversation usually happens in a single meeting. The client describes what they want. We ask two questions: what breaks if this ships a month late, and who on your team will be our point of contact after launch?
If the answer to the first is "nothing catastrophic" and the second is a name and a phone number, we're probably a fit. If the first answer is "we lose the funding round" or the second is silence, we refer them to a larger shop.
We've also started asking a third question, more recently: what does success look like in year two? If the answer involves scaling a team of six to maintain what we build, we're the wrong starting point. The handover cost will eat whatever savings the client got from hiring us instead of a mid-sized agency.
None of this is about capability in the abstract. We could probably build the marketplace. But "probably buildable" and "sustainable by three people past launch" are different thresholds, and we've learned to treat them that way.