The bounded SKU model: why we don't sell time

Engineering vendors sell one of two things, almost always:

1. Time — hourly billing, monthly retainer, a pod of N engineers for Q quarters. The vendor's revenue is hours invoiced. The buyer's accountability is "did the team work the hours."
2. Outcomes — a defined deliverable shipped on a calendar date for a fixed price. The vendor's revenue is deliverables shipped. The buyer's accountability is "did the thing land on the date."

Both models are legitimate. Both have customers who genuinely fit better in one than the other. We picked the second one on purpose, and this post is why.

What's wrong with selling time

Selling time creates a structural conflict between vendor and buyer.

The vendor's incentive is to bill more hours. The buyer's incentive is to ship what they need. These two only align when the vendor is genuinely incompetent and would otherwise need more hours to ship — which is the wrong reason to align.

When the vendor is good, the conflict is real:

• Quick wins get padded into bigger projects.
• Discovery cycles stretch out (more billable hours, no risk to delivery commitment because there isn't one).
• Scope creep becomes a feature, not a bug.
• The "ten-minute fix" turns into a quarter of work because nobody's going to volunteer to bill less.

We're not making the vendors out as villains. The model creates these incentives. Even good people working under bad incentives drift toward the bad behavior.

What "bounded" means

A bounded SKU has four properties:

1. Defined scope. The thing you're buying is a specific deliverable — a marketing site, a 21-day pentest, a TestFlight prototype. Not "engineering capacity."
2. Defined price. Published. On the page. Same number for the first buyer and the hundredth.
3. Defined date. Calendar days, not best-effort. We commit to a delivery date when we accept the deposit.
4. Defined refund mechanism. If we miss the date for reasons within our control, the 25% missed-deadline refund pays out. Real teeth on the date commitment.

Take any of those four away and you've got a different product. Take all four away and you've got "let's chat."

What changes for the buyer

The buying experience changes:

• No discovery call to see prices. Because the price is on the page. The visitor decides whether the SKU fits before any human conversation.
• No proposal cycle. Because there's nothing to propose. The scope is the SKU description; the price is the SKU price; the date is the SKU timeline plus deposit-clearing date.
• No scope-change roulette. Because the SKU is what it is. If you need more, you book another SKU; we don't "fold it in" with vague timeline impact.
• No invoice surprise. Because there's no hourly meter.

This buying experience is unfamiliar to anyone who's spent a career buying engineering services. The first reaction is usually "wait, that can't be all of it." It's all of it.

What changes for the vendor

For us, the bounded model forces several disciplines we wouldn't otherwise have:

• SKU sizing has to be honest. If we mis-size a SKU and it consistently takes longer than the timeline, we lose money. There's no hourly fallback. So the SKUs have to be right.
• Scope guardrails matter. What counts as in-scope vs out-of- scope has to be written down clearly enough that we can defend it in a conversation with a customer who wants more.
• Throughput, not utilization. Hourly shops optimize for utilization (every engineer-hour billable). We optimize for throughput (how many SKUs ship per quarter). Different metric, different operations.
• Quality is a survival trait. A bad delivery on a bounded SKU costs us the future relationship plus 25% of the contract back. In an hourly shop, a bad sprint is just more billable cleanup.

Where the model breaks

We've written about this before in /blog/when-not-to-pick-hayaiti — the bounded SKU shape doesn't fit:

• Multi-quarter staff augmentation (BairesDev, Toptal pods)
• Ongoing capacity engagements where the work is genuinely open-ended
• Founder relationships where the vendor is filling in for a CTO who hasn't been hired yet

For those, an hourly retainer or staff-aug arrangement is the right shape. We have an Embedded Engineer subscription for the closest-to-bounded version of that need, but it's still a different product than a SKU.

What this looks like in practice

Visit /pricing. Every SKU has a published price + a published timeline + a deliverable description that fits in two paragraphs. Click "Book" on the one that fits, pay 50%, the work starts within days of deposit clearing.

If you don't see your scope on the page — email us. We'll either quote it as a custom SKU same-day, point you to a vendor whose model fits better, or tell you honestly that we're not the right shape for that work.

The unit of accountability is the SKU. That's the whole product.