What the 14-day promise actually costs us — and why we still do it.

The cold open

Last Tuesday I told a 40-person SaaS company we weren’t right for their build. They had the budget. They had the timeline. The founder was on the call himself — the rare prospect who actually picks up his own customer calls. They were ready to wire 50% on the same call.

I still said no.

What they wanted was a four-month rebuild of an internal admin tool, with three departments’ sign-off on each milestone. There’s no version of that we can ship in 14 days where the client looks at it and says yes, this is the thing. Which means there’s a version where, on day 14, they look at it and say no — and under our promise, we eat the entire build. That “no” would have been earned. So we said no first, on the call, before either of us had any sunk cost.

The math nobody talks about

People assume the 14-day-or-pay-nothing promise costs us when a client says no on day 14. We’ve never had one. The cost is everywhere else.

Here’s the actual math for a 2-person studio. A 14-day engagement is roughly 200 working hours across both founders. At the rate we’d earn doing time-and-materials work for the same client, that’s a real number — mid six-figures in INR, low five-figures in USD. If on day 14 the client says no, we’ve lost 200 hours of opportunity cost, plus the cost of running the discovery process that got us there.

So the question isn’t "what does a no cost us." The question is "what does preventing a no cost us." And the answer is — almost everything else about how we run.

We turn down a third of qualified inbound. We won’t take on a second concurrent engagement until day 5 of the first. We won’t accept a project where the decision-maker is one rung removed from the call. None of that shows up on a P&L line called "cost of guarantee." It shows up as revenue we never booked. Which is harder to see, easier to argue about with yourself at 11 PM, and exactly the cost the promise actually carries.

What scoping really looks like

The discovery call is mine. Aman joins for the second half if the first half went somewhere. The first half is 25 minutes of me asking five questions, in roughly this order:

• What does the workflow look like today — specifically, who clicks what?
• What’s the one outcome that would make this build a yes on day 14?
• Who, by name, has to look at it and approve?
• What’s the smallest version of this that would still solve the actual problem?
• If we showed you a working v0 in 72 hours, what would you want to see in it?

The answers tell me almost everything I need. If the answer to question three is more than one name, the project is at risk. If the answer to question four is "well, ideally everything", we’re probably not going to ship something they like in 14 days. If the answer to question five is a shrug, the prospect hasn’t thought about it concretely enough — and concrete thinking is what the next two weeks are going to demand from them.

I say no on the call, not by email later. Email-no is cowardly — it lets you dodge the part where the prospect pushes back, asks "what if we reduced the scope", and reveals whether the underlying ask was actually flexible. Half the saved engagements come from that pushback. The other half — the ones where the pushback doesn’t come or doesn’t hold — were going to be a day-14 disappointment, and a no on the discovery call is the cheapest version of that conversation that exists.

Disqualifies a project for us: multi-quarter scope, a regulated workflow with no test fixture, a founder who refers to us as "vendors", a sign-off committee of three or more, "we’ll know it when we see it" framing on the core deliverable.

Qualifies a project for us: a one-line problem statement the founder can repeat without notes, exactly one decision-maker who reads our WhatsApp updates, a willingness to look at a rough v0 in 72 hours and tell us what’s wrong with it, and an existing manual workflow we can sit next to and watch.

The cost of the daily-update discipline

Every active engagement gets a WhatsApp update at 7 PM. Aman builds; I write the update. That second pass is 30 to 45 minutes per engagement per day. Doesn’t sound like much. Across a 14-day build, it’s 7–10 of my hours. Across two concurrent engagements, it’s a third of my working week.

We do it because the alternative is silence, and silence is where clients assume the worst. The update is three short paragraphs. What we built today. What we’re building tomorrow. One specific thing we need from them — a credential, a decision, a 10-minute call. The "specific ask" line is the whole point. It pulls the client into the loop daily, so on day 14 they’ve already been part of every meaningful decision and the final review is a formality.

Honest paragraph: this scales fine at one engagement. It’s tight at two. At three concurrent engagements it breaks, and I know it breaks because I’ve done it once and the updates got generic, and generic updates are worse than no updates — they sound like an agency status report and trigger exactly the trust problem they were meant to prevent. We cap at two concurrent for this reason. Not because we couldn’t code three. Because I couldn’t write three honest updates a day.

The price we pay for “you pay nothing”

Three operational habits we keep because of the promise — not because they’re elegant, but because dropping any one of them would put a no on day 14 within striking distance.

Conservatively scoped from the first call. Whatever we agree to in the SOW, we’re mentally budgeting against a scope about 15% smaller. That gap is where the unexpected lives — the third-party API that returns a stale field once a week, the client’s actual data being shaped nothing like the sample, the regulatory check we didn’t know existed. The buffer is the difference between shipping on day 12 with two days of hardening and shipping on day 14 with no slack at all. We give that 15% back to the client as bonus polish if nothing eats it. Something usually eats it.

No cold outreach. Ever. Cold inbound is too low-signal — the discovery hours would get burned on bad-fit prospects, and discovery hours are the most expensive hours we have because they’re mine, they don’t scale, and they’re the only thing standing between a yes-call and a 200-hour write-off. Every prospect we take on came through someone who knew us already. The pipeline is slower. The conversion is brutal in the other direction.

The no-fit conversation happens on the call. Already wrote about this above, but it’s the load-bearing one. The promise only works if the qualifying conversation is honest. Email retreats let us avoid the awkward moment and end up costing us 14 days a quarter or two later.

What we’d lose if we dropped it

The promise filters bad clients. That’s the whole product. The agencies we’d be competing with bill on time-and-materials, which means their incentive sits opposite the client’s outcome — the longer the build takes, the more they earn. We can’t play that game and don’t want to. Our incentive sits next to the client’s — if the thing isn’t right on day 14, we don’t eat well that month. So we both want the same outcome on the same date, and the contract is a single page instead of forty.

Close

We do this because we’d rather walk than work on the wrong thing. The 14-day window is short enough that you find out you’re on the wrong thing before it’s expensive — for the client and for us. Most of what looks like a guarantee from the outside is a forcing function on the inside. It forces me to say no on the call. It forces Aman to build smaller. It forces both of us to write honest updates at 7 PM every day for two weeks. The promise is the cheapest way I’ve found to keep a small studio honest with itself.

And on the Tuesdays when I have to turn down a 40-person SaaS company that was ready to pay — that’s the bill. I pay it, because the alternative bill is bigger and shows up later.