Before I Wrote More Code, I Had to Figure Out What IPMAT Actually Tests

Once I had decided to build my own IPMAT verbal practice app, there was an obvious next step.

Start coding.

Except I realised pretty quickly that I had a bigger problem.

I didn't actually know what I should put inside it.

Not in the vague sense.

Obviously there would be vocabulary.

Obviously there would be questions.

Obviously it was meant to help with IPMAT.

But if I wanted the app to be genuinely useful instead of just looking like an exam-prep app, I needed much better answers.

Which words mattered?

What kinds of questions should appear?

How much grammar?

How much reading?

Should vocabulary be taught directly or mostly through questions?

How difficult should everything be?

And perhaps the most dangerous question of all:

How much content is enough?

That sent me into the research phase.

Two books, two very different jobs

A lot of my vocabulary preparation revolved around two resources:

Word Power Made Easy

and

BlackBook.

At first, it was tempting to treat both of them as content databases.

Extract everything.

Put it in the app.

Congratulations, enormous vocabulary product.

But the more I looked at them, the less sense that made.

Word Power Made Easy is useful because of the way it teaches.

It doesn't just throw isolated definitions at you.

It connects words through roots, related meanings and families.

You start noticing why words mean what they mean.

That makes vocabulary feel less like memorising thousands of unrelated objects.

BlackBook serves a different purpose.

It gives enormous breadth.

There are huge numbers of words, idioms, phrases and other verbal material.

That is useful when preparing for competitive exams.

But there was a problem.

Having access to an enormous vocabulary list does not mean every word deserves equal attention.

And if I simply imported everything, I would be making that decision for the user without actually knowing whether it was a good one.

More content is not automatically better

This became one of the earliest principles of the project.

Suppose I tell someone:

"My app has 20,000 words."

That sounds impressive.

Much more impressive than:

"My app has 500 words."

But what does the first number actually tell you?

Nothing about relevance.

Nothing about retention.

Nothing about whether the words appear in the exams you care about.

Nothing about whether you will ever see them again after learning them once.

Nothing about whether the app understands which ones you personally keep forgetting.

A massive library can become a vanity metric.

I didn't want to build a museum of English words.

I wanted something that helps me score better.

Those are very different goals.

So I started from the exam instead

Instead of asking:

"What can I put into the app?"

I started asking:

"What does the exam actually demand from me?"

That sounds obvious.

It wasn't.

Competitive exam preparation can easily become detached from the actual exam.

You buy a large book because it is considered comprehensive.

Then you buy another resource because it contains something the first one doesn't.

Then someone sends you a PDF.

Then there is a vocabulary list online.

Soon your preparation becomes an attempt to complete resources rather than improve the skills being tested.

I did not want the app to reproduce that problem digitally.

So the content needed an evidence hierarchy.

Exam relevance first.

Useful learning structure second.

Raw volume somewhere much lower.

Vocabulary was only part of the picture

This research also confirmed something I had already started suspecting.

Calling this a "vocabulary app" was becoming inaccurate.

Vocabulary might have been the reason I started building it, but the verbal section is broader.

A student needs to deal with things like:

Vocabulary in context.

Synonyms and antonyms.

Sentence usage.

Grammar.

Paragraph-based questions.

Reading comprehension.

And the exact balance varies across exams.

That meant the underlying system needed to understand topics, not just words.

Once I realised that, the architecture of the product changed.

A question wasn't simply:

"Question number 17."

It needed information attached to it.

What skill does this test?

How difficult is it?

Which answer is correct?

Why are the others wrong?

Has the student seen it before?

Did they answer it correctly?

Should it appear again?

Suddenly I wasn't building a flashcard viewer anymore.

I was building the beginnings of a practice engine.

I did not want to copy books into an app

There was another decision I felt strongly about.

If the app existed only because I took exercises from existing books and put buttons around them, I wouldn't find that particularly interesting.

The books were there to help me understand the material.

They could influence the structure.

They could help identify useful vocabulary.

They could help me understand categories and difficulty.

But the actual question bank should consist of original questions.

That made the project harder.

It also made it much more useful.

Because creating original questions forces you to think about what you are testing.

A bad vocabulary question becomes obvious when you have to write the alternatives yourself.

A grammar explanation becomes obviously weak when you try to explain why three options are wrong.

And a question that technically works can still be useless if it tests trivia instead of the skill you care about.

Creating the content became part of designing the product.

Relevance needed to be traceable

I also wanted to avoid another problem.

Imagine the app eventually contains hundreds or thousands of questions.

Six months later I look at one and ask:

Why is this here?

If the answer is:

"I don't know, we added it at some point"

then the content system has already started decaying.

So the long-term idea became to maintain some form of research trail.

Where did a topic come from?

What exam or preparation source made it relevant?

What skill is the question supposed to test?

Is this core material or an edge case?

That doesn't sound exciting compared to animations or XP.

But if this app ever becomes large, that boring layer may be one of the most important parts.

Otherwise quantity slowly destroys quality.

The scope became clearer

After all of this, the product I wanted was much easier to describe.

It was not:

A giant vocabulary database for IPMAT.

It was closer to:

A focused verbal practice system for IIM undergraduate entrance preparation, built around relevant questions, mistakes and repeated learning.

That sentence is less catchy.

But it is much closer to what I actually wanted.

Vocabulary would still have a major role.

Eventually it could have its own dedicated learning system.

But questions would be central from the beginning.

Because I didn't only want to know whether I recognised a definition.

I wanted to know whether I could use that knowledge when the answer wasn't obvious.

Then came the uncomfortable part

Research can become another form of procrastination.

There is always another paper to inspect.

Another previous-year question to analyse.

Another book chapter to categorise.

Another feature architecture to design.

Eventually you have to stop planning and make something bad enough to test.

So I gave the first version a deliberately tiny target.

I did not need thousands of questions.

I needed enough questions to find out whether the loop worked.

I did not need a perfect adaptive algorithm.

I needed the app to remember what I got wrong.

I did not need accounts and cloud infrastructure.

I needed to be able to open it on my computer and actually practise.

That became the next milestone.

32 original questions.

A few verbal categories.

Short practice sets.

A review system.

Basic progress tracking.

No giant database.

No fancy intelligence.

No pretending the product was finished.

Just the first version that could finally answer the question I had been asking since the beginning:

Would I actually use this to study?