I Built the Quant App I Wish I Had for IPMAT

I could have built Quant very quickly.

That was exactly why I didn't want to.

By the time I started seriously thinking about a Quant application, I already knew how easy it was to make something that looked like a study product.

Questions.

Four options.

Timer.

Accuracy.

Dashboard.

Done.

Except Verbal had already taught me that a question screen is not a learning system.

Progress needs to survive.

Mistakes need to return.

Analytics needs evidence.

Exam mode needs real rules.

Content needs provenance.

Sync eventually becomes an engineering problem.

So when I started Quant, I did not want to rediscover those lessons from zero.

Quant could not be Verbal with numbers

Verbal and Quant belong to the same exam.

They do not behave like the same subject.

Quant has different failure modes.

I can know a concept and calculate badly.

I can calculate correctly but too slowly.

I can know a formula and fail to recognise when it applies.

I can be strong untimed and weak under exam pressure.

I can spend four minutes solving something correctly that should have been skipped.

Those differences change what the product needs to observe.

So Quant would share principles with Verbal.

Not assumptions.

I started with the syllabus instead of the interface

The early Verbal app started with questions.

Quant started with a map.

Topics.

Subtopics.

Formats.

Difficulty.

Exam relevance.

Dependencies.

Short Answer.

Calculation.

DI.

Timed performance.

If the underlying taxonomy is bad, almost every later feature becomes misleading.

Weakness analysis becomes misleading.

Coverage becomes misleading.

Recommendations become misleading.

So the first problem was not:

What should the dashboard look like?

It was:

What does Quant actually contain?

Then I built the smallest complete loop

Open Practice.

Choose something.

Solve.

Submit.

Understand.

Continue.

Finish.

That basic learner loop had to work before the impressive stuff mattered.

So the core solving engine supported MCQ and Short Answer, submit, skip, bookmark, timing, question state, explanations and session completion.

The goal was simple:

A student can actually practise.

Short Answer made the product more honest

Multiple-choice is convenient for software.

Short Answer is not.

What counts as an equivalent numeric answer?

What about decimals?

Fractions?

Negative values?

Tolerance?

Formatting?

Historical question versions?

These sound like implementation details until the app grades someone incorrectly.

The exam should shape the application.

The application should not quietly reshape the exam because one format is easier to code.

Wrong answers needed somewhere to go

A weak question bank does this:

Question.

Wrong.

Explanation.

Next.

Gone.

I wanted the mistake to matter later.

So Quant got Review.

Mistakes.

Bookmarks.

Repair.

Formula reference.

Retry.

The question after a miss became:

What should happen because I got this wrong?

Practice creates evidence.

Review closes the loop.

Formula memory deserved real retrieval

Seeing a formula and thinking:

I know that

does not prove much.

Recognition is cheap.

Retrieval is harder.

Application is harder again.

So formula work cannot become a static cheat sheet pretending to be learning.

The goal is measurable recall and use.

That part still needs deeper work, but the rule is already clear:

Looking at a formula is not evidence that I can use it.

Timing became part of the evidence

Two learners can both have 80% accuracy and be in completely different states.

One may be slow on easy questions.

The other may be handling hard questions at exam pace.

Or one may be accurate untimed and collapse when the clock matters.

So time could not remain decorative.

Difficulty.

Accuracy.

Time.

Timed versus untimed.

Those relationships became part of the product.

Mastery and exam execution are different

This became one of the most important distinctions.

Do I understand this?

and

Can I execute this under exam conditions?

are different questions.

A student can have good conceptual mastery and poor timed performance.

Another can be fast but conceptually fragile.

The product should not collapse both into:

Study this topic more.

Sometimes the topic is not the problem.

Quant needed drills

Sometimes I do not need normal mixed practice.

I need speed.

Accuracy.

Short Answer.

Calculation.

DI.

Hard questions.

That led to the drill architecture.

The architecture is ahead of the final verified content supply in some areas.

That is intentional.

I would rather have an honest empty state than fill every surface with weak material just so the product looks complete.

DI needed a set-level model

A chart or table is not simply several unrelated questions.

There is shared context.

Interpretation time.

Set-level structure.

Accessibility.

Potential dependency between questions.

So DI needed its own set model rather than being forced into the same structure as an isolated arithmetic problem.

Small modelling choices decide whether the product can grow cleanly later.

Then came the test engine

Practice is flexible.

Tests are not.

A test needs stronger rules around timing, sections, order, submission, navigation, marked-for-review state, recovery and scoring.

So Quant got versioned tests, server-created attempts, question state, event history and server-side scoring.

But this introduced an important distinction:

A test engine is not the same thing as a finished test bank.

The architecture can exist before verified exam configurations and content do.

That is where Quant still is in several areas.

I refuse to fill the gap with fake official papers.

PYQs created the same issue

A question found online is not automatically a verified PYQ.

Official?

Sample?

Memory-based?

Reconstructed?

Which year?

Which exam?

Was the source verified?

The PYQ layer was designed around provenance before scale.

That means the architecture is ready while the real corpus still needs proper verification.

Content debt is easier to understand than trust debt.

Analytics came after trustworthy attempts

I like graphs.

Quant eventually got plenty of them.

But I did not want analytics to be the foundation.

The foundation needed to be attempts, sessions, topics, review, timing and enough evidence to say something.

Only then does a mastery chart deserve to exist.

The current system can reason about accuracy, pace, difficulty, recent change, mistakes, mastery and readiness.

And every advanced conclusion needs another question:

How much evidence do we have?

None.

Low.

Moderate.

Strong.

Sometimes that label matters more than the score.

I would rather show insufficient evidence

Dashboards hate blank space.

But if a student has answered three questions, the responsible conclusion may simply be:

I don't know yet.

If there is not enough timed evidence, do not claim readiness.

If a reference threshold has not been verified, do not invent one.

If a topic has one attempt, do not pretend its mastery is known.

Empty is sometimes the most intelligent state.

Recommendations needed reasons

The app eventually gained a Today's Focus system.

But I did not want:

Practice Algebra

appearing because some invisible algorithm felt like it.

A recommendation should have a reason.

Due review.

Unrepaired mistakes.

Weakest evidence-backed topic.

Or, for a new learner, a baseline diagnostic.

Simple interface.

Defensible reason underneath.

Quant got serious persistence earlier

Verbal taught me not to build months of product around fragile local-only state.

Attempts matter.

Sessions matter.

Bookmarks matter.

Review matters.

History matters.

So Quant got ownership and sync architecture much earlier.

That work is still not finished.

Larger histories, reconnect behaviour, account switching, resumable sessions and validated derived evidence still need hardening.

But at least those problems are visible before launch.

Then the interface had to catch up

The engineering became better than the product felt.

The app looked too much like an internal dashboard.

So I rebuilt it.

Home became more visual.

Practice became easier to enter.

Solving became Focus Mode.

Review became about repair.

Analytics became readable.

Tests became clearer.

Achievements got their own place.

The product gained charts, mastery visuals, activity views and stronger mobile behaviour.

That deserves its own article.

The product is much larger than the content

This is still the main reality check.

The architecture is broad.

The real reviewed content is not yet broad enough to sustain long-term preparation.

Several domains need coverage.

PYQs need real verification.

DI needs enough good sets.

Tests need real assessments.

Exam rules need proper checking.

This is not a small remaining task.

Code can make ten thousand questions fit into a product.

Code cannot make ten thousand questions good.

That is why I am not filling the empty spaces with garbage

A PYQ page without verified PYQs is not impressive.

A mock engine without good mocks is not preparation.

A readiness score without evidence is not intelligence.

A syllabus with one token question per topic is not coverage.

The architecture can wait for trustworthy content.

That is less exciting.

It is also true.

Building Quant after Verbal felt completely different

Verbal was discovery.

Quant started with more judgment.

I knew the kinds of mistakes that would hurt later.

I knew review mattered.

I knew analytics could lie.

I knew sync would become serious.

I knew tests needed stronger rules.

So Quant grew faster.

Not because Quant is easier.

Because the first app paid for a lot of the education.

The real reusable asset was not the code.

It was judgment.

The goal is still simple

I want to open Quant.

See what matters.

Start quickly.

Solve something relevant.

Understand why I got it wrong.

Repair it.

Know whether I am improving.

Know whether I am becoming faster at being wrong.

Know whether a weakness is conceptual or execution-related.

Know when the app does not have enough evidence.

And when I am done:

leave.

No maintenance ritual.

No pretending a dashboard is studying.

Just a very good place to get better at IPMAT Quant.

Now I actually have to finish it.