Business Model Complexity Map

The Model Has to Survive the Week

A price can be easy to state and expensive to honor. A $99 subscription may require account state, recurring payment recovery, usage limits, cancellation, continuous support, and a product reliable enough to use without the founder. A $600 assisted review may need one invoice, a written scope, a delivery ledger, and several hours of careful work. The subscription looks simpler on the pricing page. The review may be the simpler company.

Use this map after the pricing hypothesis sheet, before committing to a paid pilot, subscription, usage plan, transaction fee, marketplace, freemium offer, API business, or services-plus-software model. Return to it when revenue grows but support, implementation, disputes, variable cost, or manual delivery begins to consume the founder’s week.

Bring the proposed exchange, product and positioning boundaries, delivery steps, support notes, data and trust requirements, known costs, and evidence from real offers or customers. Map the model that could be operated now. A mature version with a team, stable volume, and earned trust answers a different question.

Write the Operating Contract

Start with one customer promise:

[Buyer] pays [amount and cadence] for [bounded entitlement]. We provide [outcome and delivery condition], support [named problems through named channel], and stop at [explicit boundary]. If [payment, delivery, or cancellation exception] occurs, [policy].

Then name the present learning question. The contract might need to reveal whether customers will pay for the outcome, whether a value unit makes sense, whether delivery can be repeated, or whether the founder can support the promise economically. Do not ask the first model to answer all four at once.

A label such as subscription, marketplace, or usage-based SaaS is not an operating contract. It hides the customer-visible limits and the machinery behind them. Write the promise literally enough that a customer could object to it and the founder could determine whether it was fulfilled.

Follow One Customer Through the Machinery

Keep one working page. Put the model, customer promise, learning question, owner, and reconsideration date at the top. Then trace a normal customer from agreement through exit. For each of the following paths, record four things: the normal path, the most likely exception, the current boundary or policy, and what the next few customers must teach.

Money

Follow the price into an invoice or charge, receipt, failed payment, refund or dispute, cancellation, and reconciliation. Name which steps are manual and where the commercial record lives. A payment link may be enough; an undocumented promise remembered from email is not.

Access and data

Record what the customer may use, what limit applies, and how the product recognizes the entitlement. Then follow every required input through collection, storage, permissions, export, retention, and deletion. State what changes when payment stops. A plan boundary is product state even when the founder enforces it by hand.

Delivery and implementation

Walk from agreement to first value. Include setup, mapping, migration, training, data cleanup, review, and customer approval. “Onboarding” is too broad to reveal where founder judgment enters. Name the step and the time it consumes.

Support and exceptions

List the questions, failures, and reasonable correction requests created by the promise. Choose a channel and response boundary. Decide what happens when the customer exceeds the package, supplies unusable input, requests custom work, or disagrees that the promised result was delivered.

Trust and exit

Ask what the customer risks if the product is late, wrong, unavailable, insecure, or difficult to leave. Record the proof and safeguards the current offer can honestly provide. Then write the exit path: unfinished work, access, stored data, exports, final charges, and any continuing obligation.

Variable cash cost

Calculate the cash that rises with each customer or unit: payment fees, infrastructure, model calls, storage, third-party APIs, refunds, contractors, and delivery costs. Test ordinary use and a plausible heavy-use case. A flat price becomes dangerous when the variable side is invisible or unbounded.

Founder week

Place sales, setup, delivery, support, finance, monitoring, and recovery work on an actual week alongside product development and customer learning. Record founder hours separately from cash cost. A model that fits only when no input is messy, no payment fails, and no customer asks for help does not fit.

Find the Burden That Dominates

Do not average the paths into a reassuring score. One extreme obligation can determine the company: a two-sided marketplace with no liquidity, an enterprise sale with security work the founder cannot satisfy, an AI plan with unbounded review cost, or a service whose custom setup consumes every available hour.

Stress the map with one bad but ordinary week. A customer pays late, another sends malformed data, a third needs a correction before an important meeting, and usage is higher than expected. Which promise breaks first? What must the founder stop doing to recover? That point is the model’s present constraint.

Mark each path with one of four decisions:

• Accept when the normal path and likely exception can be handled consistently at the present volume.
• Simplify when a narrower entitlement, supported input, delivery window, support promise, or payment method preserves the learning question.
• Defer when the model needs scale, liquidity, procurement trust, compliance capability, or automation the business has not earned.
• Reject when the offer depends on unbounded cost, hidden labor, unsafe practice, or a team that revenue cannot yet support.

The decision belongs to the dominant burden, not the most attractive revenue shape.

Modeled Map: One Assisted Review Cycle

This modeled example continues the fictional field-service product from the preceding templates. It demonstrates the map; it is not market evidence.

The founder proposes this contract:

An operations manager pays $600 once for an assisted review of one scheduling export containing up to 500 job records. The founder returns an editable list of source-linked completeness flags within two business days and provides one 30-minute handoff by video call. Input repair, interpretation of service outcomes, client communication, native integrations, and ongoing monitoring are outside the offer. If the supplied export does not match the agreed shape, the founder pauses delivery and asks for a corrected file rather than repairing it silently.

The learning question is whether managers will pay for a bounded review whose output helps them begin record repair before a recurring client update.

Money is simple. The founder sends a written order and invoice, records payment and delivery status in one ledger, and does not begin work before payment. There is no recurring charge, proration, seat state, or usage billing. A cancellation before work begins receives a refund; after work begins, the written terms govern the bounded delivery rather than an improvised concession.

Access and data carry more weight. Each order covers one accepted export and one editable result. The founder records receipt, processing, delivery, and scheduled deletion, stores no data beyond what the review needs, and uses an agreed transfer path. A changed export schema stops the normal path because hidden cleanup would alter both delivery time and the evidence being collected.

Delivery requires judgment but has a boundary. The founder maps the agreed columns, runs deterministic completeness checks, reviews the flags for obvious mapping failures, and returns the list. The manager decides what each flag means and repairs the source record. The founder supports the review mechanism, not the customer’s client reporting.

Support and trust are visible in the handoff. The customer may ask why a row was flagged, correct a mapping, or report a missing source link through email and the scheduled call. The product does not claim that an unflagged record is accurate, and the founder does not turn ambiguous operational history into a confident client-facing conclusion.

Cash cost is bounded; founder time is the pressure point. Payment, compute, storage, and delivery cost can be recorded per cycle, but the model fails if mapping, quality review, and handoff routinely crowd out the next sale or product improvement. The founder therefore records time by step and treats bespoke input repair as excluded work, not invisible customer acquisition cost.

The bad-week test exposes data intake and founder review time before billing. The resulting decision is:

Accept the paid review for the next three qualified customers. Keep one export shape, one review cycle, and one support path. Simplify or stop if mapping and review exceed the delivery boundary twice; do not offer a recurring or unlimited plan until the useful output, revision pattern, and founder time per cycle are understood.

The map has not proved a scalable business. It has made the next commercial learning safe and legible.

Keep the Map Current

Revise the working page when a real exception changes the promise, cost, or founder week. Preserve the earlier version with the evidence that forced the change. Repeated manual work may deserve automation; repeated custom work may instead reveal that the entitlement is too broad.

The map is ready when the founder can trace one customer from agreement through exit, identify the first obligation likely to outrun the evidence, state how the current offer contains it, and name the observation that would justify a heavier model. Once that contract fits one founder’s week, the next task is to put it in front of the right customer without disguising what the company can deliver.