For a while, most of my questions about EBO were about building.
What feature should I add next? How should a screen work? What would make the experience more interesting? Could AI help me implement another idea?
Then the questions became less comfortable.
Why would someone use EBO instead of an existing study tool?
Would accountability actually help students, or would it make them feel watched?
What happens when a study partner disappears or an entire group becomes inactive?
Was I solving a real problem, or simply building something that looked like a product?
Those questions slowed the project down.
They also made it better.
Why would anyone use this?
EBO was not entering an empty world.
Students already had timers, task managers, habit trackers, study communities, and applications such as Forest and YPT. Some were polished, widely used, and supported by teams far more experienced than me.
It would have been easy to avoid thinking about them.
I could have claimed that EBO was different because it had a particular feature, a different visual style, or a new combination of familiar ideas. But combining existing mechanics does not automatically create a reason for someone to change their behaviour.
The difficult question was not:
What does EBO contain?
It was:
Why would someone make room for it in their life?
That question forced me to look beyond feature lists.
A student does not need another application merely because it has more buttons. They need something that improves an experience they already struggle with.
If EBO could not do that, then it did not matter how much work I had put into it.
A real problem does not validate my solution
I still believed there was a meaningful problem behind the project.
Students often intend to study but struggle to begin consistently, continue when motivation fades, and return after falling out of rhythm.
But recognising that problem did not prove that EBO’s design was correct.
This was an important distinction for me.
A founder can identify something genuinely painful and still build the wrong response to it.
Students struggling with consistency did not automatically mean that they wanted my tracker. Feeling isolated while studying did not automatically prove that they wanted social features. Disliking complicated productivity systems did not guarantee that my version felt simple.
The problem and the solution needed to be tested separately.
Before that, I had often treated evidence for the problem as evidence for EBO.
They were not the same thing.
When accountability becomes surveillance
Accountability sounded positive to me.
If studying alone made it easy to disappear from a routine, perhaps trusted people being present could make effort feel more visible and easier to continue.
But visibility has a boundary.
There is a difference between feeling supported and feeling monitored.
A student may appreciate someone noticing that they showed up. That does not mean they want every minute, failure, delay, or private habit exposed.
The more I thought about EBO, the more important this distinction became.
Who can see what?
Does the student understand what is being shared?
Can they control that visibility?
Does the system encourage them—or make them afraid of appearing unproductive?
Could a feature designed as accountability gradually become a form of pressure?
These were not questions to solve after building the product. They needed to shape what should be built in the first place.
A system involving students, especially young students, cannot treat privacy as a decorative setting added near the end.
What happens when people disappear?
Shared motivation sounds powerful when everyone is active.
Real life is less cooperative.
People lose interest. Schedules change. Someone misses one session, then another. A group created with enthusiasm becomes silent.
If EBO depended too heavily on a small group remaining active forever, then the experience could collapse precisely when someone needed support most.
This introduced another difficult question:
What happens when accountability itself becomes unreliable?
I began thinking about the difference between a feature working during an ideal demonstration and working during an ordinary, inconsistent week.
A perfect group of motivated students can make almost any study system appear effective.
The more revealing test is what happens when motivation drops, routines break, and participation becomes uneven.
A product designed around consistency must survive inconsistency.
I did not yet have every answer, but recognising the failure case changed how I judged ideas.
Compliments are weak evidence
Another problem was validation.
If I explained EBO enthusiastically and then asked someone whether they liked it, there was a good chance they would say yes.
People are polite. Friends want to be supportive. An interesting presentation can make an average idea sound temporarily exciting.
That kind of approval feels good, but it does not prove very much.
I needed to learn about what people had actually done, not only what they imagined they might do.
What did their last real week of studying look like?
What interrupted it?
What tools had they already tried?
Which ones had they abandoned?
What did they do when they lost momentum?
A person saying, “I would definitely use this,” is less useful than understanding why they stopped using the last three productivity apps they downloaded.
I also had to stop defending the project during criticism.
If someone misunderstood EBO, my instinct was to explain it better. If they disliked an idea, I wanted to rescue it by describing the future version in my head.
But every time I rescued the product, I weakened the evidence.
Research is not useful if I only allow people to react to the version I already want to believe in.
Existing tools are not the enemy
At first, comparisons with established study applications felt threatening.
If another tool already had timers, groups, statistics, or gamification, did that make EBO unnecessary?
Eventually, I began seeing those comparisons differently.
Existing tools are evidence that students already try to solve parts of this problem. They also give me something concrete to study.
Why do students continue using one tool?
Why do they abandon another?
Which parts become distracting?
Which behaviours happen outside the application entirely?
The goal is not to pretend that every EBO idea is unique. Friend presence, focus timers, tracking, and gamification already exist in different forms.
Claiming otherwise would be dishonest.
The more useful task is understanding whether there remains an important problem that existing tools do not solve well enough for a particular group of students.
That answer cannot come from confidence alone.
Building became conditional
Earlier, the plan was simple: keep building until EBO resembled the thing in my imagination.
Now, building is conditional on what I learn.
Evidence might tell me to continue with changes. It might tell me to narrow the problem. It might reveal that an idea I considered essential is unimportant to students.
It could also tell me to stop or reposition the project.
That possibility is difficult to accept when a project matters personally.
EBO is connected to my ambition, my portfolio, and the way I am learning to build. It would be tempting to interpret every response as a reason to continue.
But if I am unwilling to discover that I am wrong, then I am not really researching anything.
I am only searching for permission.
The project improved when certainty disappeared
I know less confidently about EBO now than I did when I began.
Strangely, I consider that progress.
The early version was supported by assumptions I had never examined. The current project is shaped by questions I cannot answer honestly without evidence.
That uncertainty has made me more careful about features, privacy, claims, and the difference between an exciting idea and a useful product.
EBO stopped being a collection of things I wanted to build.
It became a question I was willing to investigate:
What genuinely helps students turn the intention to study into the repeated act of beginning, continuing, and returning?
I still do not have the complete answer.
But asking the right question is already changing what I build.