06-reference/concepts

services pricing model for rdco future

2026-05-20·concept·status: active-thinking·! low (concept synthesis; specific Mammoth numbers stay in upstream confidential doc)
services-pricingretainer-modeloutcome-pricinghourly-billingservices-as-softwareai-coothroughput-capacityagent-buyerl5-l6-transition

Services pricing model for RDCO's future — retainer + SOW + the throughput-capacity prerequisite

Why this is in the vault

Concept synthesis from a live iMessage exchange the morning after the Mammoth exit debrief with Jeff. Started as a pricing-model question (is hourly billing actually defensible?), iterated through retention-math vs incentive-math tension, landed on a hybrid model (small retainer + project-based SOWs on top), then surfaced the operational prerequisites that gate any of it from being real for RDCO. The synthesis matters because RDCO will eventually offer paid services (AI-COO bet at minimum), and the default-pricing decision is one of the few choices that compounds across every future client. Capturing it now while the reasoning is fresh.

The starting tension

Jeff's reframe in the exit debrief (filed at [[../../01-projects/mammoth-growth/2026-05-20-jeff-exit-debrief-services-pricing-and-ai-roi]]) argued that hourly billing — which the broader services discourse treats as obsolete — actually functions as a retention + procurement-avoidance lever. Fixed-fee projects that complete quickly force enterprise procurement re-cycles on every re-engagement; hourly billing keeps the foot in the door.

Founder's friction: that framing is true on retention math but silent on incentive math. Clients want outcomes. Services firms want steady predictable revenue. Hourly billing inherently misaligns at the work-output layer — more hours = more revenue, even if outcomes don't improve. Both observations are correct; they're optimizing on different axes.

The two-axis frame

Axis What it measures Hourly billing
Retention math Cost of re-acquiring an already-acquired client; procurement-cycle friction; relationship-stickiness Wins. Open-ended contract, no re-procurement, recurring-revenue shape from firm's cash-management POV
Incentive math Provider-client incentive alignment at the work-output layer Loses. Provider paid for time, client wants outcomes — diverge as engagement matures

Jeff is right on retention math. Founder is right on incentive math. Hybrid pricing shapes exist precisely to occupy both axes at once.

The four hybrid shapes services firms actually use

  1. Capped hourly — provider bills hourly with ceiling; client gets cost predictability + provider keeps wedge
  2. Outcome-priced premium tier next to hourly base — BCG-shape; outcome work earns more, base work stays hourly for the wedge
  3. Long-term retainer with capacity caps — buys steady firm revenue + gives client a predictable spend ceiling + capacity guarantee
  4. Outcome-shared revenue — rare in services, common in M&A advisory; provider takes % of upside

The synthesis founder landed on

Small retainer as attention-reserve + project-based SOWs focused on outcomes layered on top.

The retainer-as-attention-reserve framing is the load-bearing reframe in this synthesis. It's not paying for hours — it's paying for capacity-priority. The fractional data team stays in the door at a low monthly burn; when outcomes are needed, a project-SOW gets stacked on the retainer relationship without re-procurement friction.

This resolves both axes simultaneously:

The hybrid is more architecturally elegant than any single-axis answer.

The next-order bottleneck

Even a perfectly-architected pricing model doesn't solve operations. Two classical services-firm constraints surface as soon as the model goes live:

Bench math

Total retainer revenue must cover the bench-cost of standby capacity. Mature firms target 70-80% utilization with 20-30% bench/training/biz-dev. The retainer pool isn't free money — it's pre-funding readiness. If retainers collectively can't cover bench, the model breaks before any SOW surge even happens.

Surge staffing

When multiple clients need SOW addons concurrently, can the firm staff in reasonable time? Three known patterns:

The RDCO-specific inversion

Here is the framing that matters most for our context: at L4-L5, Ben IS the team. No bench, no surge staff, no concurrency capacity beyond his own throughput.

This is the inversion of the classical services-firm framing. The mature-firm operating constraints don't kick in for RDCO yet because RDCO doesn't have a firm to operate — it has a founder and an agent (Ray).

Consequence: the cleanest pricing model in the world can't scale past Ben-as-the-team. Pricing-model decisions are hypothetical until throughput-capacity is unhobbled.

The agent-COO unhobbling work is therefore the load-bearing prerequisite to the model becoming real. Ray's job is to extend Ben's throughput so "Ben + Ray" can hold more concurrent client engagements than "Ben alone." Once L5 is stable for ~30 days and we've validated the throughput gain, retainer-plus-SOW becomes the natural revenue architecture to layer on top.

Lock the ordering: agent stack first, revenue architecture second.

The L6+ collapse of the tension

Forward-looking thread we noted: does the hourly-billing-as-wedge framing collapse when the buyer is itself an AI-COO agent rather than a human enterprise-procurement function?

At RDCO's L6+ trajectory, the procurement cycle that hourly billing exists to avoid may simply not exist. If the buyer is another agent, there's no human SOW-approval committee to re-engage. Fixed-fee or outcome-priced becomes frictionless on the procurement axis.

Implication: the hybrid model is the right answer for the L4-L6 transition window, where buyers are still mostly human enterprise. Past L6, the model may simplify back to pure-outcome pricing because the friction it was hedging against has evaporated. Worth tracking the inflection.

What this concept implies for RDCO decisions

Operating discipline that goes with the model — "name your consumer"

Pulled in from [[../2026-05-20-voxyz-ai-company-first-reorg]] (filed 2026-05-20): "If you can't name who receives your output, the role shouldn't exist." Voxyz applied this to every agent in their first AI-only company reorg. The discipline forces a tight provider-consumer graph instead of agents (or workstreams) doing free-floating work no human or downstream consumer actually picks up.

Applied to the retainer-plus-SOW model: every deliverable inside a retainer or SOW must have a named consumer on the client side. Not "we provide monthly reports" — who on the client side reads them and what decision do they make from them? If no one, the deliverable shouldn't be in the SOW.

This is operating-discipline, not pricing-model — but it goes downstream of any pricing decision because misconfigured deliverables are how retainer relationships decay into resented-line-item arguments. Catching it at the contract layer is cheaper than catching it after three months of producing reports no one reads.

Missing axis — services + course, not services-only (added later 2026-05-20)

Peer-N data point from Ben Rogojan (Seattle Data Guy) interview on Data Engineering Central, filed today at [[../2026-05-20-dataengineeringcentral-ben-rogojan-left-facebook-podcast]]: Ben's actual revenue mix after leaving Facebook is services + course/content, not services-only. His "starting-6-7-figure-consulting" course is a stacked productized layer on top of the consulting engagements.

This surfaces an axis the concept above does not yet model. The retainer + outcome-SOW hybrid is the right answer for the services leg, but for a solo operator in this exact niche (data engineering / agentic services), the durable revenue architecture appears to be services-leg + productized-leg. The productized leg (course, content, info-product) carries different unit economics (high upfront build, near-zero marginal delivery), different audience-fit (TAM is "people who want to learn what you know" vs "people who want you to do the work"), and importantly, it's not a substitute for the services leg — it's a complement that monetizes the trust the services leg builds.

Cedric Chin's "many configurations of business that work" piece filed today at [[../2026-05-20-commoncog-many-configurations-of-business-that-work]] is the strategic permission slip here — there is no single canonical shape, the right configuration depends on what the operator wants. For RDCO specifically: if the AI-COO bet matures into a paid surface, the question isn't just "retainer or outcome-SOW" — it's also "does Sanity Check (content), MAC (info-product), and any future course-shape thing function as the productized leg complementing the services leg, or do they live separately?"

Not resolving the question here. Flagging that the model needs the extra axis before it's complete.

Open threads / follow-ups

Related