Pricing the Cut

Consider a fictional pricing example. A founder reads a proposal for a two-week subtraction phase, staffed by two engineers at a low-five-figure fee, and asks why he should pay to receive less code. The scenes, budgets and outcomes in this chapter illustrate a possible commercial structure. They are not audited engagement figures or Sliday’s current rate card. Mason’s separately attributed interview below is a real source.

In the example, the studio rewrites the line item to describe the outcome.

The rewritten proposal says production readiness assessment and remediation. It lists a dependency audit, a test-coverage baseline, a performance benchmark, a refactor plan and a remediated repository tagged at a named commit. The fee and work stay the same; the founder can now identify what he will receive. Suppose he signs and the team removes forty per cent of the code. That outcome is part of the example, not a measured result.

The pricing problem for Sculpting work is, at its root, a translation problem. An unfamiliar line item reads, to a CFO trained on a decade of software procurement, as either a euphemism or a mistake. You solve the problem by writing a rate card the CFO can recognise.

Three pricing choices follow from that example.

The first choice is to stop treating hours or lines written as the headline measure of value. An engineer can spend an hour adding reviewed code or removing an unused subsystem. The number of lines does not tell the client whether the product improved. Name the intended result: fewer dependencies, a faster build or a flow users can complete.

That does not require replacing hourly billing throughout an engagement. One possible structure puts fixed milestones at the start and capped time-and-materials maintenance at the end. The structure draws on Ryan Singer’s Shape Up (2019), which describes fixed-time, variable-scope appetites. Here the founder brings the prototype and the studio agrees an appetite for improving it.¹

The difference from Singer’s version is the direction of the appetite. Shape Up appetites bound the additive work of building a new feature. Sculpting appetites bound the subtractive work of removing what the prototype brought with it.

The second choice concerns the subtraction phase. A time box with a named outcome can make the fee understandable even when nobody knows how many lines will go. In the example, use two weeks and two engineers, with measurable acceptance criteria and an agreed overrun cap. Those numbers illustrate a quote; the codebase and available team determine the actual allowance.

Name the phases before quoting them. An illustrative sequence is Audit (repository assessment, with an agreed fee and cap), Subtraction phase (a time box with named outcomes), Hardening (milestones based on the retained code) and Ongoing sculpting (maintenance within a monthly cap). The half-day deletion meeting in The Discipline of Subtraction is a decision ritual within that work, not another name for this two-week phase.

A useful outcome would be a founder asking for another subtraction phase on a new flow because they understand what the first one bought. The aim is repeatable language for the work, not a euphemism for removing code.

The third choice concerns the hardening phase.

Hardening is where the studio re-prices. The audit says what the prototype is, the subtraction phase removes what it should not have been, and hardening turns what remains into software people the founder has never met can run. The three phases are not the same shape of work, and they need not use the same fee structure.

Mason’s interview describes the boundary between a prototype and delivered software. Mason Filippi races sports cars for a living and founded OpenFender, a platform that helps drivers find sponsors; we have built and maintained it with him since 2019. I asked him what he now does himself that he would have contracted out two years ago, and what he still refuses to touch. He prototypes, he said. He still hires out the code that reaches a user. The reason was not cost and it was not time. It was reliability, and he reached for racing to explain it without being prompted: the thing you sit inside at speed is the thing that has to hold. Asked separately what he would pay a studio for at all in 2026, he named two items. The product his users touch, and the marketing.

That describes the value of hardening and continuing support from a client’s perspective. It is also the honest answer to the question the subtraction phase raises, which is why a founder who can now build the first version himself would pay anybody for the second.

A single hardening fee quoted before the subtraction phase can fail in both directions. If the retained code is cleaner than expected, the client may feel overcharged. If removing code reveals hidden structural problems, the studio may absorb an overrun. The quote needs to state how the parties will handle either outcome.

Re-quoting after subtraction can give the studio a better estimate, but a client who expected a fixed total may experience it as a change in the deal. Tell them at the start which figures are estimates and which are commitments.

One proposed structure quotes hardening as a range with two gates. At the end of the subtraction phase, the studio narrows the range against the retained repository. At an agreed mid-hardening review, the parties fix the remaining figure or revise scope. The client sees the range and both gates at the start.

The parties can use two gates to narrow a hardening estimate. Its purpose is to price against what the repository reveals while making the next decision visible to the founder.

The retainer is the fourth piece, and it is the one the studio has to be most disciplined about.

Retainers work when the founder genuinely continues to sculpt. They fail when the founder wants feature-factory output. The failure mode is identical every time: the retainer is signed on the basis of ongoing subtractive maintenance, the founder’s priorities shift three months in towards a new customer-requested feature, the studio is asked to build the feature under the retainer, the retainer hours evaporate on addition rather than subtraction and six months later the engagement has quietly reverted to a 2022-shaped build contract billed at a 2026-shaped retainer rate. Both sides are unhappy. The studio’s margin collapses. The founder feels short-changed on the feature velocity they believe they were paying for.

At the start of a retainer conversation, ask what the founder expects to remove or maintain during the next ninety days. If they want new features, decide whether those features belong in the cap or require a separate quote. Write the distinction down before the work begins.

The figures below are fictional budgets for three example products. They illustrate the fee structure and do not establish studio revenue or efficiency gains.

Across the three examples the numbers run roughly like this. The audit runs at a four-figure fee in every case. The subtraction phase comes in at a low five-figure fee for the fintech and insurance cases, four-figure for the consumer-health one. Hardening is mid five-figure for fintech and insurance, low five-figure for consumer-health. The retainer runs at a low five-figure monthly rate for two of the three and a four-figure rate for the consumer-health engagement. Total twelve-month engagement value lands at mid six-figure for fintech and insurance, low six-figure for consumer-health. The equivalent 2022 time-and-materials quote (a hypothetical comparison budget for the same end-product) would have been high six-figure for the fintech and insurance engagements, mid six-figure for consumer-health.

In these examples, the total fee falls below the hypothetical build quote because the founder supplies the prototype. That result follows from the illustrative budgets. A studio needs its own cost and revenue records to decide whether higher realisation, repeat work and retainers can replace the revenue it previously earned on the first build.

A studio pricing this work needs to explain the remaining value and cover the cost of delivering it. These example budgets do not establish what competing studios charge or whether their pipelines are growing.

The studios that survive this era will be the ones that stopped billing for the code and started billing for what the code no longer needs to be.