EBO was never supposed to be a product.
There was no market analysis, business model, customer profile, or grand plan behind its beginning. I wasn’t trying to build a startup, and I certainly wasn’t imagining institutions using it.
I originally created it for one person: myself.
I was a student trying to understand my own time and become more consistent with studying. Like most students, I didn’t have a shortage of intentions. I knew what I was supposed to do. I could make plans, set goals, and promise myself that tomorrow would be different.
The harder part was repeatedly beginning the work, continuing when the initial motivation disappeared, and returning after an unproductive day.
I wanted something simple that could make my effort visible to me.
That small personal need became EBO.
The first version was just a tracker
The earliest version focused on tracking parts of my day.
How much time did I spend studying? How much did I sleep? How much time did I waste?
These were not sophisticated questions. I wasn’t thinking about behavioural science, product research, institutional requirements, or long-term retention. I just wanted a clearer picture of what I was actually doing.
There is an uncomfortable difference between feeling busy and seeing how you used your time.
A tracker seemed capable of making that difference visible.
So I tried to build one.
At the time, my technical ability was extremely limited. I wasn’t a programmer who had identified a problem and then calmly engineered a solution. I was someone with an idea, incomplete knowledge, and a willingness to keep experimenting until something appeared on the screen.
The result existed, but it was far from the product I imagined in my head.
Building became part of the motivation
Once I had something basic, the project became exciting for reasons beyond studying.
I could add points. I could create rewards and badges. I could experiment with themes, achievements, music, and different ways of presenting progress.
Every new feature made the project feel more complete.
It also made me feel capable.
When you are building your first project, visible additions are addictive. A new button, animation, screen, or reward system gives you immediate proof that the project is moving forward. It is much harder to measure whether the thing is becoming genuinely useful.
At that stage, I wasn’t asking enough difficult questions.
I was mostly asking:
What else can I add?
I had not yet learned to ask:
Why should this exist?
That distinction would eventually change the entire project.
The first attempt didn’t become what I wanted
The original EBO did not become a serious product.
Part of the problem was technical. I didn’t yet have the knowledge required to build, maintain, and improve everything I imagined. My ambition was much larger than my ability to implement it reliably.
But the deeper problem wasn’t merely that I lacked coding skills.
I had started with my own experience and immediately jumped to a solution.
I knew that I struggled with consistency, so I assumed tracking would help. Then I assumed that points, rewards, and more features would make the tracking better.
I had not separated the problem from my proposed solution.
I had not spoken to enough people. I had not tested whether other students experienced the problem in the same way. I had not asked whether they wanted another tracker—or whether tracking was even the most useful response.
I had built something before properly understanding what needed to be built.
The first attempt failed to become what I wanted, but it gave me something more valuable than a polished application: a collection of unanswered questions.
My problem might not have been mine alone
Even though EBO began only for me, the behaviour behind it didn’t seem unique.
Students often know that they need to study. Information is rarely the only missing ingredient. Timetables, lectures, resources, and advice already exist everywhere.
Yet knowing what to do does not guarantee that someone will begin doing it.
Starting can be difficult. Continuing can be lonely. Missing one day can quietly become missing an entire week. When nobody else can see the effort disappearing, it becomes easy to keep postponing the return.
That observation made me wonder whether EBO could become something larger than my personal tracker.
But it also created a more dangerous possibility: perhaps I was assuming that because I experienced a problem, everyone else must experience it in exactly the same way.
That is where EBO began changing from a small coding experiment into a product-thinking experiment.
The central question was no longer:
How can I improve my tracker?
It became:
What actually helps students remain consistent—and how do we know?
I started questioning the product itself
Once I treated EBO as something that might be used by other people, the standard changed.
A feature could no longer exist merely because I found it interesting. It needed a reason.
Would students actually use this?
Would it help them return to their work, or only make them feel guilty about what they had not done?
Would accountability be encouraging, or would it become surveillance?
Would rewards support real habits, or distract from them?
Was I solving a meaningful problem, or creating another colourful productivity system that people would abandon after a week?
AI could help me produce more code and more features. It could suggest interfaces, mechanics, and technical approaches.
It could not answer those questions for me.
Answering them required research, judgment, conversations, testing, and the willingness to discover that my favourite ideas might be wrong.
From building features to testing assumptions
The most important change in EBO was not visual or technical.
It was a change in how I thought.
Instead of treating every new feature as progress, I began treating every assumption as something that needed evidence.
The personal problem that started EBO still mattered. I still wanted to understand why intentions so often fail to become consistent action.
But I could no longer assume that my own answer was automatically the right answer for everyone else.
That meant slowing down.
It meant separating the student’s problem from the solution I wanted to build. It meant listening for rejection instead of searching only for encouragement. It meant being prepared to narrow the idea, change it, or even abandon parts of it.
For someone who enjoys turning ideas into visible things, that is surprisingly difficult.
Adding a feature feels like movement.
Changing your mind can feel like going backwards, even when it is the most meaningful progress you have made.
What EBO means to me now
EBO is still a working codename, and the project may eventually be called something completely different.
It is no longer simply the tracker I first wanted for myself. It has become an attempt to understand student consistency, accountability, privacy, and the gap between planning to work and actually returning to it every day.
I am deliberately not presenting it as a finished solution.
There are still assumptions to test, questions to answer, and ideas that may not survive contact with reality.
That uncertainty is not something I want to hide.
EBO began because I wanted to solve a problem in my own life. Its evolution began when I realised that building for other people requires more than turning my personal preferences into features.
The first version taught me how exciting it feels to make an idea visible.
Everything since then has been teaching me something harder:
Before building the product, I need to understand the problem.