The Non-Technical Founder's Escalation Ladder: 7 Decisions You Own, 23 We Take Off Your Desk

What an escalation ladder is, and why we write one before the first sprint

An escalation ladder is a written contract that states, decision by decision, which calls the founder signs off on and which the engineering team makes alone. We sort every recurring decision by consequence class: reversibility, spend, compliance exposure, and customer visibility. Anything failing two or more classes goes to the founder.

Non-technical founders usually arrive with one of two defaults. Either they approve nothing, which means the team invents a proxy for founder intent and gets it subtly wrong for three months, or they approve everything, which turns the founder into a queue. Neither default is a decision about authority. It is the absence of one.

So we write it down at kickoff, before there is a codebase to argue about. The document is one page. It lists the escalations by name, the threshold that triggers them, and the response window we expect. It is revised, in writing, whenever a threshold turns out to be wrong, and both of ours did.

The four consequence classes we sort decisions by

We classify every decision against four tests: is it reversible within one sprint, does it commit spend above the agreed threshold, does it touch personal or regulated data, and will a customer see it. A decision that fails one test is usually ours. A decision that fails two or more is the founder's.

Reversibility is the strongest test and the least intuitive to founders. Choosing a state management library is a decision engineers can undo in a week. Choosing a payments provider is not, because it drags KYC flows, refund semantics, and eighteen months of transaction history behind it. Founders often want to weigh in on the first and skip the second, because the first has a name they recognise.

Compliance exposure overrides everything else. On GlycanAge, a regulated health-tech platform, decisions about consent scope and when a biological age result becomes visible to a customer are not engineering decisions at any threshold. A clinician gates result release. The founder owns the policy. Engineers implement it and audit it. There is no version of that ladder where a developer quietly changes what a consent checkbox covers.

• • Reversibility: can we undo this within one sprint without data loss or customer notice?
• • Spend: does it create recurring cost above the agreed monthly threshold, or a contract term longer than the engagement?
• • Compliance exposure: does it touch PII, consent scope, retention, or a regulated release gate?
• • Customer visibility: will an existing user notice a change in behaviour, pricing, or available features?

The 7 decisions we ask the founder to own

Seven decision types stay with the founder permanently, regardless of how technical they become over the engagement. Each one either cannot be reversed cheaply, commits money the founder has to find, or carries legal weight that a contractor cannot absorb on the founder's behalf.

These are deliberately few. A short list is one a founder can actually hold in their head, and a founder who knows exactly which seven things will come to them stops treating every Slack message as a potential ambush. We also commit to a response window on each, usually 48 hours, with a written default that applies if we do not hear back. The default is the part founders appreciate most, because it means their silence does not stall a sprint.

• • Scope cuts that remove a promised customer-facing feature, including cuts forced by an App Store or Play Store rejection.
• • Any vendor commitment that creates lock-in beyond the engagement: payments, identity, email, analytics, lab or logistics integrations.
• • Consent scope, data retention periods, and what a user is told at the point of collection.
• • Pricing, billing logic, and anything that changes what a customer is charged or when.
• • Which regulated gates exist and who holds them, for example clinician sign-off before a result is released.
• • Recurring infrastructure and on-call spend above the agreed monthly ceiling.
• • Launch dates and the definition of what counts as shipped.

The 23 we take off the founder's desk

Everything else is ours by default: framework and library choices, schema design, test strategy, CI configuration, code review standards, error handling, logging, caching, index design, deployment topology, and the rest. These are reversible, invisible to customers, and cost the founder nothing to be wrong about once.

The categories founders find hardest to hand over are the ones with visible names. Database choice is one. Hosting provider is another. Both feel enormous because they appear in every technical article a founder has ever read, and both are, in practice, decisions we can revisit. We have moved workloads off Firestore into Postgres mid-engagement without the founder needing to approve anything beyond the resulting cost line, because cost is the part that hits their ladder.

Two categories sit on the boundary and get handled as notifications rather than approvals. Schema-breaking migrations are the first: we own the migration, but the founder gets written notice with a rollback window, because a botched migration is customer-visible even though the decision is technical. Third-party API version bumps are the second, for the same reason. A notification is not a request for permission. It is a record that the founder was told, which matters enormously when someone asks six months later why a report changed shape.

• • Ours outright: language, framework, component library, state management, folder structure, build tooling.
• • Ours outright: data model, indexes, query patterns, caching, background job design, retry and backoff policy.
• • Ours outright: CI pipeline, environments, branch strategy, code review checklist, linting and type rules.
• • Ours outright: monitoring, alert thresholds, log retention within compliance limits, error grouping.
• • Ours with written notice: schema-breaking migrations, dependency major versions, provider swaps with no cost delta.
• • Ours with written notice: performance work that changes observable app behaviour, such as pagination limits.

The two escalations we set too high, and had to lower

We got two thresholds wrong and revised the ladder mid-engagement. The first was App Store submission scope, which we initially treated as a team decision. The second was recurring infrastructure spend, where our ceiling was high enough that meaningful cost drift never reached the founder until it appeared on an invoice.

On MOVE & MEET, a London fitness community we took from spreadsheets to a shipped iOS and Android app, the founder came from an operations background and had never dealt with app review. Our original ladder said submission readiness was an engineering call. Then a review rejection landed and the fix required cutting a feature the founder had already told members about. That conversation should not have been an unplanned phone call. We rewrote the ladder so that anything altering what a submitted build contains is a founder decision, made before submission rather than after rejection, with the likely rejection reasons listed in advance.

The spend threshold failed differently. We set the ceiling per-decision rather than per-month, so a series of individually small additions, an extra environment here, a log retention bump there, never tripped it. Now the ladder measures the monthly run rate against a ceiling the founder set, and the escalation fires on the trend, not the individual change. Plodovi's four-year engagement runs on that version, with the operations lead rather than a technical hire owning the cost line.

The founder who wanted to own everything, and what it cost

One founder rejected the ladder and asked to approve every technical decision, including library choices and pull requests. The result was not better software. It was a cycle time dominated by waiting, where the median time from a decision being ready to a decision being made stretched from same-day to several days, and engineers batched questions into weekly calls to avoid blocking.

The failure mode is worth naming precisely, because it is not about competence. The founder was smart and engaged. But approving a decision you cannot evaluate produces a rubber stamp with extra latency attached. The questions that got real scrutiny were the ones the founder recognised, which meant naming conventions received more attention than a retry policy that later caused duplicate charges in a test environment.

We renegotiated to a hybrid: the founder kept the seven, plus a standing weekly review of everything we had decided in the previous week, presented as a list with one-line rationales. Same visibility, no blocking. That artifact, a decision log paired with a ladder, is what we now default to. The ladder says who decides. The log says what was decided. Founders who feel exposed by delegation usually need the second document more than they need veto power over the first.

How to write your own ladder in an afternoon

Take the last twenty technical questions that reached you, score each against the four consequence classes, and put anything failing two or more on your list. Then write a default action for every item on that list, so silence resolves rather than stalls. Circulate it, and revise it in writing when a threshold proves wrong.

The practical detail most people miss is the response window. A ladder without one converts founder authority into a bottleneck the first week a founder travels. Pick a window per item, 48 hours for scope and spend, longer for anything requiring legal or clinical input, and pair it with an explicit default. "If we do not hear back in 48 hours, we ship the smaller scope and log it" is a legitimate outcome. "We wait indefinitely" is not.

Allocating decision rights is the core of what a fractional CTO actually sells, more than architecture opinions or hiring help. If you are a non-technical founder without one, the ladder is the cheapest version of the same thing: a document that tells everyone which calls are yours, which are not, and what happens when nobody answers.

The App Store rejection that forced us to lower a threshold is described in more detail in our MOVE & MEET case study, covering the move from spreadsheet operations to a shipped iOS and Android app.