The First Version Had Only 32 Questions

Eventually, I had to stop researching.

I knew why I wanted the app.

I had thought about what IPMAT verbal ability actually tests.

I had looked at the role of vocabulary, grammar, reading and other verbal skills.

I had decided that dumping thousands of words into a database was not the same thing as building a useful learning system.

There was only one problem.

I still didn't have an app.

I had an idea.

A lot of notes.

A rough product philosophy.

And absolutely no evidence that I would actually enjoy studying with the thing I was designing.

So I gave myself a much smaller goal.

Build something usable.

Not impressive.

Not scalable.

Not ready for other students.

Just usable.

The first question bank had 32 questions

Thirty-two.

That's it.

Not 3,200.

Not an enormous AI-generated question bank.

Thirty-two original questions.

They covered a few different parts of verbal ability, including vocabulary, grammar, paragraph-based skills and reading.

That number was obviously nowhere near enough for a real exam-preparation product.

But that wasn't what I needed yet.

I needed enough variety to test the experience.

Could I open the app and start practising quickly?

Would short practice sessions feel useful?

Would I understand why I got something wrong?

Would I want missed questions to return?

Would it be easier than manually jumping between books, notes and random resources?

Those questions mattered more than the size of the database.

Six questions at a time

The first practice format was deliberately short.

A set contained up to six questions.

I liked six because it made starting almost frictionless.

A 50-question mock requires commitment.

Six questions doesn't.

You can open the app thinking:

"I'll just do one set."

And a few minutes later you've actually practised something.

That seemed much better for daily use.

The system also tried to prioritise questions I had not already seen instead of immediately recycling the same material.

At this stage there was no complicated adaptive engine deciding exactly what my brain needed next.

It was much simpler than that.

Give me useful questions.

Prefer unseen ones.

Remember what happened.

That was enough.

Practice was only one part of the loop

Very early on, I realised that answering questions wasn't enough.

Suppose I get a question wrong.

The app shows me the explanation.

I understand it.

Then I never see the question again.

What exactly did we accomplish?

Probably less than it feels like.

So the first version started developing three clear areas:

Practice

Review

Progress

Practice was where I solved new sets.

Review was where mistakes and saved questions lived.

Progress was where the app could start showing me what I had actually done.

That structure seems obvious now.

It wasn't obvious when the app was just an idea.

Wrong answers needed somewhere to go

This became one of the first features that made the app feel meaningfully different from solving questions on a webpage.

If I answered something incorrectly, it could enter my review pool.

Later I could encounter it again.

If I eventually answered it correctly, the app could treat that mistake as repaired.

That created a tiny learning loop:

Get something wrong.

Understand why.

See it again.

Get it right.

Move on.

Simple.

But much more useful than allowing mistakes to disappear forever.

Bookmarks were different from mistakes

I also wanted the ability to save questions intentionally.

That sounds similar to the wrong-answer system, but they serve different purposes.

A wrong answer means:

I struggled with this.

A bookmark means:

I want to keep this.

Maybe the question teaches an interesting word.

Maybe the explanation is useful.

Maybe I got it right but still don't completely trust myself.

So correcting a previously missed question shouldn't automatically delete a bookmark.

Those two pieces of state needed to remain separate.

This was one of the first times I started noticing how many tiny decisions hide inside apparently simple features.

"Add bookmarks" sounds like one line on a feature list.

Actually building them forces you to define what a bookmark means.

There were no accounts

This is probably my favourite thing about the first version.

There was no authentication system.

No email verification.

No profiles.

No password reset flow.

No cloud database.

No account settings page.

Nothing.

The app stored attempts, bookmarks and preferences in the browser.

That meant I could refresh the page and still keep my recorded progress on that device.

Was that good enough for a finished product?

Absolutely not.

Was it good enough to test whether the core experience worked?

Yes.

And that distinction saved a lot of unnecessary work.

I deliberately avoided Supabase at first

I already knew that if the app became serious, I would eventually want proper accounts and cloud sync.

Supabase was an obvious candidate.

But adding a backend before I even knew whether I liked practising with the app would have been backwards.

It would have meant spending time solving:

Authentication.

Database schemas.

Sync behaviour.

Network errors.

Permissions.

Account recovery.

Multi-device conflicts.

Before answering the much simpler question:

Is the practice experience any good?

So the first version stayed local.

One browser.

One student.

Me.

The app worked on my phone and computer

I built it as a responsive web app first.

That gave me something useful immediately.

I could open it on my laptop while working.

I could use it on my phone while studying.

And I didn't need to build separate Android, iOS and Windows applications just to validate a practice loop.

At the time, I wasn't thinking about app stores.

I was thinking about whether I would actually come back tomorrow.

Then I started using it

This is where things became interesting.

There is a huge difference between looking at something you built and using it because you actually need it.

When you're admiring your own project, every animation feels exciting.

When you're trying to study, you stop caring.

You notice friction immediately.

You notice when a button takes too long to reach.

You notice when a practice set feels repetitive.

You notice when progress isn't clear.

You notice when an explanation technically exists but doesn't really teach you anything.

You notice when something looks impressive but contributes absolutely nothing to the reason you opened the app.

That was the advantage of being the first user.

I couldn't hide behind screenshots.

Thirty-two questions also exposed a problem

The app worked.

Which was good.

But that created a new problem almost immediately.

I started running out of unseen material.

With only 32 questions, repetition becomes obvious very quickly.

That meant the question bank needed to grow.

But simply adding questions would not solve everything.

The app also needed to get better at understanding what I had already seen, what I struggled with and what should come back later.

The more I used it, the more obvious it became that the interesting part wasn't going to be the question screen itself.

It was going to be the system underneath it.

Then I made it slightly addictive

Once the basic loop worked, I started wondering whether the app could make progress feel more visible.

Not because I wanted to turn studying into a mobile game.

But because studying has terrible feedback.

You can work for an hour and close a book with almost no feeling of progression.

There is no level-up screen.

No progress bar.

No obvious signal saying:

"You are better at this than you were yesterday."

So I started experimenting.

A streak.

XP.

Daily activity.

A small goal.

Better completion feedback.

Sound.

Motion.

Tiny rewards for actually showing up.

And somewhere around that point, my tiny 32-question prototype started becoming something else.

It wasn't just a place to answer questions anymore.

It was beginning to behave like a learning system.