all notes
2026-04-25Abhiraj Sakargaye

Five things we decline to build, and why.

SingleBit declines work on five specific shapes: spec builds, account-manager layering, post-launch ghosting, client overload, and feature-list briefs. Every one of them quietly trades short-term revenue for long-term damage to the product.

A list of the engagements we turn down, drawn from real conversations. Saying no is how the yes gets honest.

Every studio has a list. Most keep it private. Ours is on the site because the conversation saves time for everyone involved: us, you, and the team we'd rather hire for the thing we're not the right fit for.

We've said no to roughly a third of the work we've been offered since founding. Here's what falls in that third, and why.

1. Spec builds and unpaid pitches

If a prospective client wants us to mock a screen, a feature, or a funnel before there's a signed agreement, we decline. The work we do is thinking, not decoration, and thinking done for free gets valued accordingly by whoever commissions it.

The cost of saying no here is zero. The cost of saying yes, once, is that every subsequent prospective client expects the same thing.

The rule: a proposal is the pitch. We write a real one, tailored, inside 3 to 5 days of a fit call.

2. Engagements that need a project-manager layer

"Can you add an account manager between me and the team?" is the question. Our answer is that the account manager is the team, one of the founders directly. Every call, every Loom, every repo. Without that wire, discovery softens, decisions slow, and the founder ends up hearing about problems two weeks late via a third hand.

On SIT Manager the client had previously run through two agencies in the same layout: founder → PM → dev team. Both had quietly stalled for nine and six months respectively. Our change wasn't technical. It was structural: a direct line. First deploy inside fourteen days.

The rule: direct line, or nothing.

3. Post-launch ghosting

The industry default is: ship on Friday, invoice on Monday, silence on Tuesday. We don't do that. Before launch we agree, in writing, what the first ninety days look like. Whether we stay on retainer, whether we do a stabilisation window, or whether we hand over cleanly with a runbook. One of those three, chosen explicitly.

The alternative is a client three months after launch trying to reach the people who built their product, hitting voicemail, and finding (correctly) that the thing they paid for has quietly become their problem.

The rule: launch plus one conversation, before any code ships.

4. More clients than attention allows

Four active engagements per founder is our ceiling. We've held that number even when the pipeline said otherwise. When we've broken the rule, twice, early on, the same thing happened both times: the newest engagement absorbed what we'd committed to the oldest, and an invoice arrived for attention the client didn't receive.

The numbers backing this are boring and specific: roughly twenty-eight hours a week of deep work per founder, divided by four, is seven. Seven hours per client is the floor for the kind of work we want to do. Under that floor the work becomes the thing we criticise other agencies for.

The rule: four active per founder. Sometimes three.

5. Feature lists without a problem statement

"Here's the spec. Build it." is a brief we turn down politely. Specs are answers, answers to questions nobody wrote down. When we've ignored this rule the same pattern repeats: we ship what was asked for, the client says "this isn't quite it," and we spend a sprint reverse-engineering the actual problem while both sides pretend the scope hasn't changed.

We now ask for a problem statement before we price anything. Five sentences. What is the user trying to do, what's getting in the way, what does success look like, what's been tried, what's the constraint. If that can be written, the build can be scoped.

The rule: problem before solution, always.


Heuristics

For the other half of this, how we do scope the work we take on, see Contracts before code.


Written 2026-04-25 by Abhiraj Sakargaye.

FAQ

Questions this usually surfaces.

Do you turn down paid work?
Yes, regularly. A paid engagement that isn't going to ship, or that requires us to layer a project manager we don't believe in, costs us more in reputation than it pays in revenue.
What does SingleBit do when a project isn't a fit?
We say so on the first call and, when we can, we point the founder at a studio or freelancer we trust. An honest redirect is worth more than a misfit engagement.
How many clients does SingleBit work with at once?
Four or fewer active engagements per co-founder, capped on purpose. Beyond that, the attention tax shows up in the work.