Protocol

Deliver the small service before automating its machinery

An automation plan can hide an untested service.

When it fits

You are building infrastructure for a benefit nobody has received yet.

When to avoid it

Manual success does not prove automation feasibility, scalable economics or broad demand. Do not promise support capacity you do not have.

Why it matters

Offer a clearly bounded manual pilot to a suitable user. Agree the output, limits and human involvement, then deliver the useful result. Record the effort and repeat demand before deciding which part deserves software.

Steps

Choose a small outcome you can actually deliver without pretending the service is automated.
Agree scope, access, confidentiality and any payment terms.
Record delivery effort, revisions and whether the user would seek the service again.

An example

Before building a full corpus subscription system, a pilot delivers a small, source-checked selection for one recurring work problem.

Check your result

Did the user receive a useful outcome, and can you explain the cost of repeating the service?

Keep this limit in mind

Manual success does not prove automation feasibility, scalable economics or broad demand. Do not promise support capacity you do not have.

Connected ideas

Evidence and sources

Supports

Graham describes manually serving early users as a way to learn before scaling a service.

Practitioner advice, not causal evidence that a concierge pilot predicts commercial success.

Do Things that Don’t Scale · Manual work discussion.

All sources (1)

Do Things that Don’t Scale