You build it, you run it, you can sell the book.

Three separate components

You earn three separately defined things:

1. Milestone cash during the build. Cash at defined implementation milestones, at an illustrative 40 to 60 percent of market labor rates. The build is paid work, not speculation; the participation tail is upside on top of a wage, not a substitute for one.
2. Build Participation. 10 percent of eligible application revenue for each application you materially built. Flat, 36 months from customer acceptance, unconditional.
3. Service Participation. 10 percent of eligible application revenue while you are the assigned service owner in good standing.

Each component prices a different thing: labor delivered, value created, responsibility carried. Keeping the bases separate is what lets us make the tail unconditional without making the wage contingent.

Time to first dollar

Milestone cash arrives during the build months; participation starts only at customer acceptance. On the canonical engagement, delivering the full engineering package ($70,000 of design-and-development plus $15,000 of integration-and-deployment, $85,000 of implementation value) pays roughly $42,500 of milestone cash across the build at the 50 percent midpoint, then $900 per month of participation on the two applications from acceptance. A package split across contractors splits the cash by the same milestones.

We publish that shape because the recruiting failure mode of participation models is implying recurring income during the build. I think stating the cash-flow curve up front costs us nothing with the engineers we actually want.

The tail has no escape hatch

Build Participation is unconditional: flat 10 percent, 36 months from acceptance, non-transferable, and it survives loss of the service role. There is no contract clause that can shorten or condition it. An earlier draft of this model carried an "unless otherwise specified by contract" hatch, and we removed it, because a tail the company can zero out is not compensation a serious engineer will price in.

Churn protection follows the same logic. If the customer leaves before month 36 for reasons not attributable to you, the remaining tail settles by a defined pro-rated buyout: illustratively, 50 percent of the remaining scheduled participation, valued at trailing-3-month eligible application revenue. We control the customer relationship and the retention work, so we share the downside when a customer walks early through no fault of the builder.

The service role is real work

Service Participation pays for responsibility actually carried: on-call duty, incident response, bug remediation, maintenance, deployment support, customer assistance, and production health, against published SLAs:

• P1 acknowledged in 15 to 30 minutes and stabilized in 2 to 4 hours
• P2 acknowledged in 1 hour and mitigated same business day
• P3 acknowledged in 1 business day and scheduled
• P4 acknowledged in 2 business days and backlogged

The termination rule is structural: suspension and reassignment are the same event. The moment participation stops, the support obligation moves to another owner. No state exists in which your support obligations continue while support pay has stopped. That unpaid-but-obligated state is where support models rot: the owner stops answering pages and the customer inherits the failure.

Tier 2, our backstop engineering capacity behind every service owner, shares revenue mechanically: when the backstop does material incident work, its share is computed from logged incident ownership and hours. A Tier 1 resolution keeps your full Service Participation for the period. Repeated SLA failure triggers reassignment, which, per the rule above, is also the end of the pay. An incomplete handoff package suspends defined payments until cured.

The book is the asset

As a service owner in good standing you may sell or transfer your service book — the set of applications you own — to another qualified contractor for consideration, subject to Hadto approval and SLA-performance conditions on the buyer. The conditions exist so a customer never inherits an unqualified owner. The sale right exists because an income stream you cannot exit at a price is a job, and the transfer right is precisely what makes the book an asset instead of a revocable assignment.

The unit of account, and the two rates

All partner accounting runs on applications, not customers. Eligible application revenue is the Managed Application Fee for the specific application ($2,250 in the canonical example), and the Base Platform Fee is excluded because it pays for Hadto-operated shared infrastructure.

Two rates, and the difference between them is the honesty of every table below. During the build window (months 1 to 36 on an application you both built and service), Build plus Service Participation totals 20 percent of the application fee: $450 per month at the canonical $2,250. On a mature application (after month 36), Service Participation alone remains: 10 percent, $225 per month. The 20 percent rate always expires.

At the canonical $2,250 Managed Application Fee:

The left column describes a book where every application is inside its build window — a real state early on, never a permanent one. A real book mixes the columns, which is what the composite below does.

A mature position, from the same numbers

A coherent full-time composite from the canonical numbers: a service book of 16 applications — 12 mature at $225 per month ($2,700) and 4 inside their build windows at $450 ($1,800) — pays $4,500 per month, $54,000 per year, in participation. Two selective new builds per year, each delivered as the full engineering package, add roughly $85,000 in milestone cash ($42,500 each). Total: roughly $139,000 per year. Milestone cash is the largest component, participation is the recurring floor, and nothing in that number requires believing the 20 percent rate is permanent.

The arithmetic is exact; the trajectory is unobserved. No contractor has yet run a 16-application book with a two-build annual cadence, and we will replace this composite with actual cohort figures once the first service owners have operated books for a year.

The book size is not arbitrary either. A book is bounded by Tier 1 SLA obligations — one person can be on call for only so many production applications, and P1 acknowledgment in 15 to 30 minutes is a physical constraint, not a policy. The scaling mechanisms past that bound are the Tier 2 backstop and the specialization marketplace (AI voice, dispatch, estimating, portals, reporting, integrations, data pipelines), not heroics.

What the structure rewards

The structure points your income at engineering quality. You hold both the 10 percent and the pager for the same application, so every corner cut in the build converts directly into unpaid 2 a.m. debugging inside a fixed fee. Hourly consulting has the opposite gradient: more incidents, more billable hours. Here, income is maximized by building maintainable systems that need fewer hours over time, and poorly engineered software degrades your own on-call life before it degrades anything else.

What this is, and is not

Participation is compensation for defined work and defined operational responsibility. The service book is a transferable asset. Neither is equity — not in Hadto, not in any customer. For operators who want actual equity ownership of a service business, Hadto's separate venture path exists; it is a distinct program with its own terms, not part of this one.

Terms used on this page