Outcome billing vs. the body shop

Hourly billing rewards duration. Outcome billing rewards completion. For small, bounded builds, the difference is whether you buy a result or rent capacity.

The body shop model

Staff augmentation and open-ended T&M engagements share the same incentive structure:

• More hours means more revenue — for the vendor, not for you
• Scope expands because boundaries were never written
• Activity substitutes for progress: commits, standup attendance, tickets moved
• When the budget runs out, you have activity — not necessarily software in production

This is not malice. It is economics.

The outcome-oriented model

Output-oriented builds invert the contract:

1. Define the deliverable in production terms — what works, for whom, by when
2. Write explicit inclusions and exclusions — what is in scope, what is not, what triggers a change order
3. Demo weekly — working software, not slide progress
4. Bill against acceptance criteria — not against hours logged

You know what you are buying before the work starts.

When each model fits

| Situation | Better fit | |-----------|------------| | Discrete feature with clear acceptance criteria | Outcome-oriented build | | Ongoing capacity need with evolving backlog | Hire, don't outsource hourly | | Architecture or delivery advisory | Phased consulting with artifacts | | "We need three senior engineers for six months" | Body shop — but call it that |

Red flags

• SOW that lists headcount but not acceptance criteria
• Demos that show Jira boards instead of working software
• Invoices tied to hours with no milestone mapping
• Scope conversations that begin with "how many developers do you need?"

SierraFlux takes bounded build engagements with defined outcomes. We do not sell hours. We do not augment your staff.

If the problem is capacity, hire. If the problem is a deliverable, scope it.

For bounded builds with weekly demos and fixed outcomes, see Output-Oriented Builds.