In a screen share, the demo automation and the production automation look identical: same trigger, same steps, same green checkmarks. Everything that separates them is invisible in the demo, because everything that separates them is about what happens when nobody is watching.
An MVP exists to answer a question: is this worth doing? It succeeds the moment it runs once in front of the right people. Production exists to keep a promise: this runs every time, unattended, indefinitely. Those aren't two maturity levels of one thing; they're two different worlds, and a good share of the automation work we take over failed exactly at the border between them.
The project ends; the other world begins
Projects are what organizations know how to fund. A project has a scope, a team, a deadline, and (the defining feature) an end. Somebody presents the result, somebody applauds, the team disbands.
Maintenance is the world that starts the next morning and never ends. It has no scope, usually no budget line, and for automations often no owner. The person who built the flow moves on. The credentials they used expire in eleven months. The API it calls announces a deprecation in a newsletter nobody on the current team receives.
Software engineering learned this long ago and built institutions around it: on-call rotations, SRE, deprecation policies. Business automation mostly didn't. Flows get built project-style (by a consultant, an intern, a motivated ops person) and then enter the maintenance world with none of the equipment that world requires. The result is a landscape most companies would recognize: dozens of small automations of unknown health, alive mainly because nobody has touched them.
What the contract contains
Moving a flow from MVP to production isn't polish. It's adding properties the MVP legitimately didn't need:
- idempotency: the flow will be re-run (a crash, an impatient human, a duplicate webhook), and running twice must not mean paying twice
- retries with limits: transient failures retry with backoff; permanent ones stop and say so
- failure that reaches a person: not a log line, a message to a named owner with enough context to act
- an audit trail: what ran, when, with which inputs, touching which records (the first serious dispute makes this the most valuable artifact you own)
- versioning and rollback: last month's behaviour must be reconstructable, if only to answer "did it always do this?"
- credential hygiene: tokens rotate, service accounts outlive their creators, secrets live somewhere better than the flow definition, etc
None of this shows up in a demo. All of it decides whether the automation is still trustworthy in year two, and trustworthy-in-year-two is the actual product.
Why the gap persists
The MVP misleads because its success is visible and its incompleteness isn't. A stakeholder watches the invoice get posted and reasonably concludes the work is done; the missing idempotency key is not on the screen. So the follow-on budget, often a multiple of the MVP cost, looks like gold-plating to whoever approves budgets. It took us a while to learn to say this out loud at scoping time, before the demo rather than after. "It already works" is probably the most expensive sentence in automation.
There's a structural fix, and it's the same consolidation argument that shows up elsewhere: production properties amortize when flows share a runtime. Build retries, credential storage, audit logging, and alerting once (in the layer where every process runs), and each new flow inherits the contract instead of re-implementing it badly. This is much of the practical case for an execution layer; flow8 is one place the pattern shows up cleanly, with the audit log and failure handling as floor rather than feature. A scattered landscape of scripts pays the production tax per script; a consolidated one pays it once.
That doesn't make the second world free. It makes it survivable for teams that will never have an SRE function, which is almost every team automating business processes.
The sorting question
One question predicts more than any architecture review: who gets woken up when this breaks in eight months?
A real answer (a name, a channel, an alert that reaches them) means the automation is a product. A pause means it's a demo that has been left running. Most companies are carrying a few of those right now, quietly one API change away from their first silent failure.
If that describes some of your landscape, curious how you're deciding which ones get moved onto a real footing first. Happy to share the checklist we use, if useful!