Why most automation projects never reach production
Automating the happy path is often easy. Production begins when the system has to handle everything that happens around it.
Most automation projects begin with a satisfying moment.
Something that used to be manual starts happening on its own. A task runs without intervention. A rule executes correctly. The system produces the result you expected.
That first version can feel close to the finish line.
In reality, it is usually only the beginning.
The happy path is only the beginning
Automating the happy path is often easier than making automation dependable.
The first version assumes that inputs are valid, external services respond correctly, timing is reasonable and every previous step completed as expected. Those assumptions are useful when proving an idea, but they rarely survive production.
Real systems encounter missing data, delayed responses, partial failures, rate limits, restarts and user mistakes.
The hard part is not making automation work once. The hard part is making it behave safely when conditions are imperfect.
Production demands boring work
Many automation projects never reach production because the remaining work feels less exciting than the prototype.
Validation, permissions, observability, retry logic, state recovery and clear error handling do not create the same feeling as watching the first automated action succeed.
But these pieces are what turn a clever workflow into a usable system.
Without them, the automation may technically work, but it remains too fragile for real responsibility.
Trust is a requirement
Automation changes the user's relationship with software.
When a tool only suggests an action, the user remains in control. When a system acts automatically, trust becomes a requirement. The user needs to understand what the system is doing, when it will stop and what happens if something goes wrong.
This is especially true in trading.
A system connected to capital cannot rely on vague behaviour. It needs clear limits and predictable responses, even when the market or infrastructure is not cooperating.
The prototype hides the real scope
The first version of an automation project often hides how much work remains.
It proves that the core idea is possible, but not that the surrounding system is ready. The missing pieces are usually not obvious until the software is expected to operate continuously.
That gap explains why many projects stall.
The interesting part is done, but the responsible part has barely started.
Looking back
Building Oblivion made this lesson very concrete.
Automated trading is not only about getting a strategy to execute. It is about making sure the system can keep operating, recover from problems and protect users from the assumptions hidden inside the code.
Production begins when automation has to handle everything around the happy path.