One of the most persistent early-product debates sounds simple: should you support the first customers manually, or automate for scale?
The disagreement often comes from two teams optimizing for different risks. Product leaders worry about learning the wrong lesson from an untested workflow. Engineering leaders worry about creating an operation that cannot scale. Both concerns are valid; the sequence is what matters.
Manual work can be research
Staying manual early is not about avoiding engineering. It is about avoiding the wrong engineering.
Paul Graham’s advice to do things that do not scale and the Concierge MVP pattern point to the same idea: deliver the service by hand long enough to test the assumptions underneath it.
A useful gut-check is: if users will not pay when it is manual, they will not pay when it is automated. Automation scales value that already exists; it does not manufacture that value.
Sequence the work deliberately
- Build the parts you understand with confidence.
- Keep uncertain workflows manual so the full product can still operate.
- Watch for behaviour that genuinely repeats.
- Automate only after the pattern becomes stable.
This reframes manual operations as a deliberate product choice. The team is not avoiding the build. It is protecting the build from assumptions that have not earned permanence.
The failure mode is not starting manually. It is remaining manual after the learning is complete.
Early-stage product work is about finding the right thing before scaling it. Premature automation is technical debt that happens to look like progress.