The biggest mistake I made building Oblivion
Looking back, the biggest mistake wasn't technical. It was how I approached the project itself.
People often ask what the biggest mistake was while building Oblivion. Some expect the answer to involve a bug, a failed strategy or an architectural decision.
Surprisingly, none of those would make the top of the list.
The biggest mistake was believing that building the product was enough.
Building felt like progress
For a long time, every new feature felt like meaningful progress.
A better dashboard. A new risk management mechanism. Improved monitoring. Additional automation.
Every improvement made the platform objectively better. At least technically.
The problem was that almost nobody knew the platform existed.
Invisible products don't find users
Software does not become successful simply because it is well engineered. People have to discover it, understand it, trust it and eventually decide to use it.
Looking back, I spent years improving the product while spending very little time explaining why it existed.
That imbalance became increasingly obvious once Oblivion reached production.
Engineering and distribution are different skills
Writing software is one discipline. Helping people understand its value is another.
Neither is easier. They simply require different ways of thinking.
For someone who genuinely enjoys engineering, it is tempting to believe that a better product will naturally attract attention.
Sometimes that happens. Most of the time, it does not.
Quality is necessary. Visibility is equally important.
Sharing the journey
Starting this blog was part of correcting that mistake. Not because I wanted to market every feature. Quite the opposite.
I wanted to document the journey behind the platform.
The decisions. The trade-offs. The engineering lessons. The mistakes.
If someone eventually decides to try Oblivion, I want that decision to be based on an understanding of how the platform was built, rather than on unrealistic promises.
A different mindset
Today, I spend more time thinking about communication than I did when the project started. Not because the engineering has become less important, but because both aspects now deserve the same level of attention.
A reliable product that nobody discovers helps very few people. A popular product that lacks substance eventually disappoints its users.
The objective is to build both.
Looking back
If I could give one piece of advice to the version of myself that started this project years ago, it would be simple: start sharing the journey earlier.
Not when the platform feels finished. Not when every feature has been implemented. Much sooner.
Because software grows through iteration.
And, as I am slowly discovering, so does the audience around it.