I Killed EBO

The more EBO knew about a student's studying, the better it could supposedly help them.

That sentence is also the reason I stopped building it.

EBO is dead.

Not paused.

Not waiting for a redesign.

Not sitting on a roadmap until I find more time.

I am not building EBO as a standalone product anymore.

And the reason is not that I suddenly decided students do not struggle with consistency.

I still think they do.

It is not that the code became too difficult.

It did not.

It is not that one interview destroyed my confidence.

It did not.

And it is not because I got bored and wanted to build something else.

The problem was much more fundamental.

The better I tried to make EBO at fulfilling its purpose, the more it started violating that purpose.

That was much harder to fix than a bad feature.

EBO had a very simple reason to exist

The original problem behind EBO was never:

Students need another productivity dashboard.

Students already have calendars.

Timers.

To-do lists.

Habit trackers.

Pomodoro apps.

Study communities.

Notion templates.

Spreadsheets.

An almost unlimited number of systems for organising their lives.

The problem I cared about was what happened after all of those tools existed.

You know you should study.

You intend to study.

And somehow beginning still feels difficult.

You manage to build a routine.

Then motivation drops.

You miss a few days.

Returning becomes strangely harder than starting the first time.

That gap interested me.

So EBO's purpose became something like this:

Make meaningful studying easier to begin, easier to sustain and easier to return to.

It was supposed to feel calm.

Simple.

Useful every day.

Social when that genuinely helped.

Private enough that accountability did not become surveillance.

And, most importantly:

It should not become another productivity system the student has to manage.

That last part eventually became the problem.

At first, the product did not need to know very much

Imagine the simplest version of EBO.

I want to study.

I open the app.

I choose what I am working on.

I begin.

Maybe a friend is studying too.

When I finish, the app remembers that I showed up.

That is fairly lightweight.

There is value in making the act of beginning easier.

There might also be value in quiet social presence.

Someone else is working.

I am working.

Neither of us needs to broadcast our entire academic life.

That version of the idea still makes intuitive sense to me.

But then I wanted EBO to become smarter.

That is where things started breaking.

"Mikhil studied for two hours" tells me almost nothing

Suppose EBO records:

Mikhil studied for 2 hours today.

Great.

Was that productive?

I have no idea.

Maybe I solved difficult questions for two hours and learned a lot.

Maybe I watched lectures while barely paying attention.

Maybe I revised something I already knew because it felt comfortable.

Maybe I spent most of the session stuck on one concept.

Maybe I got almost every question wrong.

Maybe getting those questions wrong was incredibly useful because I finally discovered a weakness.

Maybe I studied for only forty minutes yesterday but did much better work.

The number 2 hours is accurate.

The conclusion someone might draw from it may not be.

So if EBO wanted to move beyond being a timer and actually tell me something intelligent about my preparation, it needed more context.

What did I study?

Which subject?

Which topic?

What questions did I attempt?

How difficult were they?

How accurate was I?

Was I learning something new or revising?

Did I understand my mistakes?

Was I focused?

Was I distracted?

Was today's shorter session actually more useful than yesterday's longer one?

Suddenly the supposedly simple study app wants to know quite a lot.

There were three bad options

This became the contradiction I could not get around.

If EBO wanted to understand studying properly, I could roughly do one of three things.

Ask the student for more information

After a session:

What did you study?

Select a subject.

Select a topic.

How difficult was it?

How focused were you?

What did you accomplish?

How many questions?

How many correct?

What kind of mistakes?

Update the task.

Mark the goal.

Categorise the session.

Rate your focus.

Now imagine doing that every day.

Maybe several times a day.

At some point, the product that was supposed to make studying easier has created administrative work around studying.

The student finishes a study session and now has homework for the study app.

That is absurd.

Collect or infer more automatically

The other option is to make EBO observe more.

More activity.

More behaviour.

More context.

More detailed history.

Maybe increasingly infer what the student was doing and whether it looked productive.

That reduces manual logging.

It creates a different problem.

Now the product needs significantly more access to the student's academic behaviour.

And even with all that information, its conclusions may still be wrong.

A system can observe activity.

It cannot automatically understand the entire reason behind that activity.

It can know I spent an hour somewhere.

It cannot necessarily know whether that hour changed what I understand.

The smarter the inference becomes, the closer I get to the surveillance problem I had already been worried about.

Or stay shallow

The final option is:

Do not collect much.

Do not ask much.

Keep EBO extremely simple.

That protects the low-friction experience.

But then I have to be honest about what the product actually knows.

Hours.

Sessions.

Streaks.

Tasks.

Maybe some basic consistency patterns.

Useful?

Possibly.

Enough to confidently tell a student how well they are preparing?

No.

And if EBO simply displayed those numbers while presenting them as meaningful academic intelligence, I would be building exactly the kind of dishonest productivity system I did not want.

Those were the three directions.

More logging.

More observation.

Or less intelligence.

None of them matched the product I thought I was building.

The productivity app was creating productivity overhead

This was the part that bothered me most.

EBO existed because studying already has enough friction.

Beginning is difficult.

Returning after inconsistency is difficult.

Keeping track of everything can become exhausting.

So why would I build another system that needs constant maintenance before it can help?

Tasks need updating.

Subjects need categorising.

Sessions need recording.

Progress needs interpreting.

Streaks need maintaining.

Groups need checking.

Accountability settings need managing.

Goals need updating.

The student now has two jobs:

Study.

And:

Maintain an accurate digital representation of studying.

The second job exists only because of the product that was supposed to make the first job easier.

That is a bad sign.

I kept imagining a student who already feels behind opening EBO after a difficult week.

Would the product make returning feel lighter?

Or would they see outdated tasks, a broken streak, unfinished goals, inactive groups and several things that need updating before the system becomes accurate again?

A product designed around returning after inconsistency cannot make inconsistency create more cleanup work.

But productivity systems naturally drift in that direction.

The smarter EBO became, the more expensive its intelligence became

Not expensive in money.

Expensive in attention.

Every piece of intelligent feedback needs evidence.

If I want to tell someone:

Your consistency is improving

I need enough history.

If I want to say:

You are spending too much time on the wrong subject

I need subject information.

If I want to say:

Your preparation quality is falling

I need some definition of preparation quality.

If I want to compare two study sessions meaningfully, I need to understand what happened inside them.

That evidence has to come from somewhere.

Either the student enters it.

The product observes it.

Or another system already has it.

EBO, by itself, did not magically possess academic truth.

That seems obvious written down.

It took me longer than it should have to understand the consequence.

Intelligence has an information cost.

And for EBO, that cost was increasingly being paid by the student.

This was exactly the surveillance problem I had already found

Earlier in the project, I wrote about accountability without surveillance.

At the time, I was mostly thinking about social visibility.

A student might want a friend to know they showed up.

That does not mean they want their entire history exposed.

They might want encouragement.

That does not mean they want every inactive day permanently interpreted as a lack of discipline.

Those concerns became even more serious once I thought about intelligence.

Because now EBO did not only want information so friends could feel present.

It wanted information so the system itself could understand the student.

And there is a dangerous progression there.

The more context the system has, the smarter it can appear.

The more context the system has, the more invasive it can become.

That does not mean collecting information is automatically wrong.

Almost every useful application uses data.

The problem was the relationship between what EBO promised and what EBO increasingly required.

I wanted a calm system.

A private system.

A low-friction system.

A system that did not judge students from incomplete evidence.

And simultaneously, I wanted meaningful intelligence about what those students were doing.

Those goals kept colliding.

Numbers were not enough

One of the earliest warning signs was how persuasive numbers looked.

Three hours.

Seven-day streak.

Five completed tasks.

Eighty focus sessions.

Twelve thousand points.

Numbers feel like evidence.

Sometimes they are.

But evidence of what?

Three hours proves that the timer recorded three hours.

It does not prove understanding.

A streak proves repeated recorded activity.

It does not prove that the activity was useful.

Points prove that the rules for earning points were triggered.

They do not prove learning.

That distinction sounds pedantic until the product starts making decisions based on those numbers.

Then it matters a lot.

If EBO displayed incomplete signals as simple records, fine.

If it started turning those signals into judgments about the student, I needed much more confidence.

And getting that confidence required exactly the additional context that created the original problem.

I kept going in circles.

Gamification made the contradiction worse

Points and streaks were attractive because they could reduce the friction of starting.

There is something satisfying about keeping a streak alive.

Watching a number increase can make progress feel visible.

That can help.

But once the metric becomes important enough, students can begin optimising for the metric.

Study because the timer needs time.

Complete something because the app needs a completed task.

Open a session because the streak needs another day.

Now EBO is no longer measuring studying.

Studying is beginning to respond to what EBO measures.

That is a dangerous feedback loop.

The goal was never:

Become excellent at using EBO.

The goal was:

Study better.

If someone could become a perfect EBO user without becoming a better student, I had built the wrong incentive system.

Accountability had the same problem

The social side of EBO was supposed to help with a very real thing.

Studying alone can make disappearing easy.

Nobody notices when you postpone something.

Nobody notices when one missed day becomes five.

Quiet presence can make starting feel easier.

I still think there is something valuable there.

But accountability only works if it stays supportive.

Once someone feels watched, the behaviour changes.

Maybe I start a session because I genuinely want to work.

Good.

Maybe I start it because I do not want my inactivity visible.

Less good.

Maybe I keep the timer running because I want my numbers to look respectable.

Bad.

Maybe I avoid the product entirely because I do not want someone interpreting a difficult week from a dashboard.

Now the accountability system has done the opposite of what it was supposed to do.

It has made returning harder.

Again, the product was colliding with its own purpose.

This was not a feature problem anymore

For a while, I kept treating these as design problems.

Maybe the logging could become simpler.

Maybe the dashboards could become calmer.

Maybe visibility controls could solve the social part.

Maybe better defaults.

Maybe fewer metrics.

Maybe smarter automation.

Maybe different gamification.

Maybe one more redesign.

Eventually I realised I was doing something dangerous.

I was assuming the product had to survive.

Every contradiction became another puzzle whose answer was:

Find a better version of EBO.

But what if the contradiction was telling me something else?

What if EBO was trying to combine things that did not belong inside one standalone product?

What if fixing one side would always weaken another?

Low friction.

Rich context.

Meaningful academic intelligence.

Privacy.

Accountability.

Minimal manual input.

Accurate conclusions.

Each one sounds reasonable individually.

Together, they were creating a product that increasingly needed to know more while promising to demand less.

That is not a small UX issue.

That is a problem with the product thesis.

The first interviews did not kill EBO

This is where I described the ending badly before.

I had started interviewing students.

Those conversations challenged assumptions.

They made some questions harder to ignore.

They reminded me that saying:

I would use this

is weak evidence.

They were useful.

But two interviews did not kill EBO.

That would be ridiculous.

They were part of a larger process that made me less willing to rescue the idea every time something uncomfortable appeared.

The same is true of competitor research.

The same is true of privacy concerns.

The same is true of feature bloat.

The same is true of questions around inactive groups.

All of those mattered.

But the final issue was inside EBO itself.

The product risked becoming another thing a student had to maintain in order for it to help them study.

That was the opposite of what I wanted.

The problem was still real

This is important.

Ending EBO does not mean I changed my mind about the original problem.

Students still struggle to begin.

They still lose routines.

They still fall behind and find it difficult to return.

Studying alone can still feel isolating.

Metrics can still be useful.

Accountability can still help.

Good feedback can still help someone understand their preparation.

Those ideas did not suddenly become false.

What changed was my belief that EBO, as a standalone productivity product, was the right container for all of them.

A real problem does not guarantee that your solution deserves to exist.

I had already written that sentence earlier in this series.

Eventually I had to act like I believed it.

I could have kept building it

That is what made the decision uncomfortable.

Nothing technically forced me to stop.

I could have spent months polishing EBO.

I could have built more dashboards.

More social systems.

More progress views.

More gamification.

More intelligence.

A better mobile experience.

I probably could have made it look extremely convincing.

That is one of the strangest things about building with AI now.

Implementation is increasingly not the main constraint.

If I can describe a feature clearly enough, there is a decent chance I can get some version of it working.

That makes saying no more important.

When building becomes cheaper, bad ideas become cheaper to continue too.

I did not want the ability to keep implementing EBO to become evidence that I should.

The hardest feature to remove was EBO

I had already removed features before.

Ideas that sounded fun.

Mechanics that added complexity.

Things that looked impressive but did not strengthen the product.

Every removal made EBO slightly clearer.

Eventually I had to consider the possibility that I was doing the same optimisation at the wrong level.

Maybe the unnecessary thing was no longer a button.

Maybe it was the product.

That sounds dramatic.

It was actually fairly quiet.

No company collapsed.

No users lost access.

No massive launch had to be cancelled.

I am seventeen.

It was an early project.

The consequence of stopping was mostly admitting that something I had spent months thinking about was not going to become what I expected.

Still difficult.

But very cheap compared with discovering the same thing years later.

I did not want sunk cost to become product strategy

By this point, EBO had documents.

Research.

Designs.

Code.

A proper showcase.

A privacy philosophy.

Interviews.

A lot of thought.

That creates emotional weight.

You start wanting the project to succeed partly because otherwise, what was all that work for?

But previous work cannot answer whether future work is justified.

If anything, the more I had invested, the more careful I needed to become.

I had written earlier that honest research needed to allow one uncomfortable outcome:

Stop.

If stopping was never allowed, then I was not researching EBO.

I was collecting reasons to continue EBO.

Eventually the evidence did not tell me:

Nobody has this problem.

It told me something more useful:

The product I designed around the problem is beginning to conflict with the problem it was supposed to solve.

That was enough.

So I killed EBO

Not the problem.

Not every idea inside it.

Not everything I learned.

EBO.

The standalone product.

I am not going to keep it labelled In Development because technically some code still exists.

I am not going to call it Paused because that sounds nicer.

I am not going to promise some future EBO 2.0 just to avoid a definitive ending.

The project is concluded.

That is the accurate status.

Some ideas can survive a dead product

Killing a product does not require pretending every idea inside it was stupid.

I still care about honest progress.

I still care about reducing friction.

I still care about helping someone return after inconsistency instead of punishing them for it.

I still think accountability can be useful when it preserves privacy and dignity.

I still think study data can help when the system understands what the data can and cannot prove.

Those principles can remain useful.

They just no longer justify keeping EBO alive as its own product.

That distinction matters to me.

Sometimes an idea is valuable and the container around it is wrong.

A project does not deserve immortality merely because some of its components are good.

I am keeping every EBO article

I thought briefly about what this ending does to the earlier build logs.

Some of them are enthusiastic.

Some describe things I no longer believe should become a standalone product.

Part 1 begins with a personal tracker.

Part 2 documents feature bloat.

Part 3 starts questioning whether EBO deserves to exist.

Part 4 wrestles with accountability and surveillance.

Part 5 tries to make the research more honest.

Part 6 shows the product becoming tangible.

Part 7 begins putting assumptions in front of other people.

And now Part 8 ends it.

I like that sequence.

Deleting the old articles would make the project look cleaner.

It would also make the story less true.

I do not want a portfolio where every project magically moves from good idea to successful execution because I removed all the evidence of uncertainty.

Sometimes the interesting part is watching the thesis break.

EBO did fail

I was too gentle about this before.

There is a version of the story where I say:

EBO didn't fail. I just learned from it.

That sounds nice.

It is also evasive.

EBO failed to become the product I expected it to become.

More importantly, the standalone product failed my own standard for what it was supposed to do.

It was meant to reduce the burden around studying.

The direction I was taking increasingly risked adding another burden.

It was meant to provide honest progress.

To make that progress genuinely intelligent, it increasingly needed information that was costly to provide or uncomfortable to collect.

It was meant to help students return.

Some of its own mechanics could make absence feel like failure.

It was meant to support accountability without surveillance.

Greater intelligence kept increasing the temptation to observe more.

That is a failure of the product thesis.

And that is okay.

Because discovering that before forcing the product into the world is useful.

Building something does not obligate me to keep it alive

I used to think persistence in building meant continuing until something worked.

I think that definition is incomplete now.

Persistence matters when the destination is still worth reaching.

Attachment is continuing because turning around would make the distance already travelled feel wasted.

I want to get better at knowing the difference.

EBO began because I wanted to understand why studying consistently can be so difficult.

For months, progress meant adding things.

Then progress meant removing things.

Then progress meant questioning the assumptions underneath the things.

Eventually the biggest question became impossible to avoid:

If EBO needs students to manage EBO so that EBO can help them manage studying, what exactly have I fixed?

I did not have an answer I believed.

So I stopped.

EBO is dead.

Not because the problem disappeared.

Because the product was beginning to become part of it.