The difference between a script and a platform
A script can automate a task. Turning that automation into a dependable product requires solving a much larger set of problems.
Oblivion started much closer to a script than a platform.
Scripts are incredibly useful because they allow an idea to move from theory to reality quickly. They help you test a concept, remove repetitive work and prove that automation can create value.
But there is a point where adding more code to a script no longer solves the real problem.
The moment other people need to depend on the system, the requirements change.
A script solves your problem
When you build software for yourself, you already understand it.
You know which settings are dangerous, what an error probably means and when restarting something is harmless. A personal script can rely on that knowledge because the user and the builder are the same person.
A product cannot make that assumption.
The software needs to communicate its own state, validate its inputs and behave predictably without requiring the person who wrote it to stand beside it.
Users change the definition of done
As Oblivion grew, responsibilities that once lived together needed clearer boundaries.
Execution, monitoring, configuration, runtime state and user-facing behaviour became different concerns. Once other people interact with a system, onboarding, permissions and predictable behaviour become part of the engineering problem too.
This changed how I judged progress.
The question was no longer only whether the automation worked for me. It was whether the platform could explain itself, protect users from obvious mistakes and continue behaving consistently when the environment changed.
Platforms need operational discipline
A script can fail loudly and wait for its creator to investigate.
A platform needs a stronger operational model. It needs logs that make sense later, alerts that point to real issues, recovery paths that do not depend on memory and interfaces that reduce ambiguity.
None of this feels exciting when compared to strategy logic.
But without it, automation remains fragile. The useful part exists, but it is surrounded by assumptions that only the original builder understands.
Trust becomes part of the architecture
A platform is not defined only by the number of features it has.
It is defined by whether people can trust it enough to rely on it. In trading software, that trust has to be earned through clarity, limits, recovery and consistency.
That pushed Oblivion away from the mindset of a tool and toward the mindset of a system.
The code still matters, but the surrounding guarantees matter just as much.
Looking back
A script proves that something can work.
A platform has to prove that it can keep working, evolve and be trusted by people other than its creator.
That difference became one of the defining engineering challenges of Oblivion.