Saying no to work we could probably pull off
Picture the pitch: a marketplace with vendor onboarding, escrow payments, real-time inventory sync, a React Native app, and an admin dashboard. A twelve-page MVP spec, wanted in eight weeks.
That is a project we turn 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 small founder-led team has a specific stress profile. It 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.
An example of the shape that fits: a quality-tracking dashboard that pulls defect data off an existing Oracle DB and surfaces it for shop-floor supervisors. Two tables, one API, one React front end, role-based access. A few weeks to ship, and easy to keep maintaining afterwards.
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 a small team past launch" are different thresholds, and we've learned to treat them that way.