Why I Built My Own IPMAT Vocab App
I had too much vocabulary to learn for IPMAT, and the tools I was using never quite matched the way I wanted to practise. So I started building my own.
Essays and build logs about products, AI, philosophy, ambition, and figuring things out while I’m still in the middle of it.
Build notes from the IPMAT preparation ecosystem I am developing—beginning with Verbal Ability and growing toward Quant, exam practice and shared preparation intelligence.
I had too much vocabulary to learn for IPMAT, and the tools I was using never quite matched the way I wanted to practise. So I started building my own.
Building an IPMAT practice app sounded simple until I had to decide what should actually go inside it. That forced me to research the exam, my books, and the difference between having more content and having useful content.
After all the research, I finally stopped planning and built the first usable version of my IPMAT verbal practice app. It had 32 questions, browser storage, short sessions, and almost nothing else.
The first version could serve questions. The next challenge was much harder: making the app remember, adapt, reward consistency, and actually help me learn over time.
The app was starting to store progress that actually mattered. That meant I had to think about offline use, syncing, Supabase, and what happens when something technically works but looks completely broken.
What started as a tiny tool for my own vocabulary backlog now has practice, review, vocabulary learning, offline progress and sync. The next stage is about turning all of that into the exam-prep app I genuinely want to use every day.
The vocabulary section had grown far beyond the 154 cards I started with. So I stopped treating vocabulary as content to browse and started building an engine that could decide what I should learn, review, and repair.
For months, I kept saying the app would eventually separate normal learning from strict exam simulation. After finishing the vocabulary engine, I finally built the exam engine properly.
The app already knew what I answered, what I got wrong, how long I took, and what kept coming back. The next step was making it interpret that evidence instead of dumping charts on me.
After building vocabulary intelligence, exam simulation and personal analytics, the next milestone was less exciting but more important: making sure progress survives bad internet, updates, sync conflicts, device changes and account actions.
The app was finally ready for scale. The next problem was content: building thousands of useful exam questions without turning the question bank into an impressive-looking pile of low-quality material.
The student-facing app was becoming more capable, but managing its questions and learning content through raw files was becoming a problem of its own. So I built a private Content Studio behind the product.
My vocabulary engine could tell when I picked the right answer. It still couldn't tell whether I could recall, distinguish, understand and retain a word. So I stopped treating one correct MCQ as proof that I knew it.
I finally found a place where AI could genuinely help the vocabulary system: giving feedback on open-ended sentence practice. But I did not want a language model deciding whether I had mastered a word.
The exam engine worked beautifully as long as nothing interrupted it. Then I started thinking about refreshes, closed tabs, crashes and unfinished attempts—and realised an active session needed to survive the real world too.
Once the app had accounts, synced progress, exam sessions and personal history, a bug stopped being something I could simply tolerate. I started hardening the product for the possibility that someone other than me might trust it.
The first version was a tiny browser app with 32 questions. It now has vocabulary learning, exam simulation, personal intelligence, accounts, sync, recovery and an entire content system behind it—but I still wouldn't call it finished.
I started by building one vocabulary app for myself. Then Verbal became a serious learning product, Quant became its own app, and I realised the interesting problem was no longer one subject—it was understanding the preparation happening across both.
Building Verbal taught me how quickly a study app can become shallow, fragile or dishonest. So when I started Quant, I approached it differently: syllabus first, evidence first, and a learning loop designed around how quantitative aptitude actually behaves.
Accuracy, time and question counts are easy to measure. Understanding what they actually mean is much harder. Building Quant analytics became an exercise in learning when a number is evidence—and when it is just decoration.
Study apps can make starting easier—or turn progress into another system to satisfy. I redesigned Quant around lower activation energy, clear finish lines, recovery after mistakes and permission to stop.
The Quant engine had become capable long before the interface felt finished. I rebuilt the learner experience around focus, hierarchy, visual evidence and a calmer path from opening the app to actually practising.
EBO failed because understanding studying required too much manual context or too much observation. Verbal and Quant changed that: the evidence now appears naturally while I study.
Once Verbal and Quant both became serious products, I needed somewhere to understand the learner across them. That became Intelligence: a separate system for synthesis, planning, retention, mocks and evidence-backed next actions.
An intelligent learning system can become dangerous the moment it presents inference as fact. So I built the learner model around observations, confidence, contradictions, versioned hypotheses and the right to say 'not enough evidence.'
Verbal, Quant and Intelligence could not become one ecosystem if each remembered the learner differently. So I started building a shared evidence platform with stable events, one identity, retries, versioned state and a common language for learning.
Getting the Verbal app to run on Android was much easier than making it feel like an Android app. Safe areas, back behaviour, haptics, keyboards, recovery and release engineering exposed the difference between packaging a website and building a mobile product.
The project that began as 32 Verbal questions now contains a deep Verbal product, a serious Quant architecture, a separate Intelligence system, a shared evidence platform and active native work. It is much larger—and still much less finished—than the screenshots suggest.
Build notes documenting the development of my local AI assistant.
SYNTHESIS began with an embarrassingly ambitious idea: I wanted a personal AI assistant that could understand my world, use tools, and actually do things—not merely answer questions.
SYNTHESIS could not become the assistant I imagined by generating better replies alone. It needed context, memory, tools, permissions, execution, and an interface built around action.
The first working version of SYNTHESIS had no voice, cinematic interface, or real intelligence. It could register two tools, judge their risk, execute one, and refuse the other—and that was enough to prove the foundation.
An AI assistant becomes useful when it can act. It becomes dangerous when action is confused with authority. SYNTHESIS is teaching me that capability must grow alongside permission, explanation, and verification.
After SYNTHESIS learned to register tools and respect permission boundaries, the next step was giving it grounded context about the computer on which it was running.
SYNTHESIS had passed its first tool, permission, model, and context tests. That proved its architecture could work—but a successful demonstration is very different from an assistant I can trust every day.
SYNTHESIS now has tested foundations for models, tools, permissions, execution, verification, and system context. Here is what genuinely works, what remains limited, and what comes next.
The complete story of a student-accountability product I researched, prototyped and ultimately chose to end as a standalone product.
EBO began as a small tool I wanted for myself. This is how a personal attempt to study more consistently slowly became a much larger product question.
The early version of EBO kept growing—trackers, points, rewards, achievements, themes, and more. It took me time to realise that adding features was not the same as building a product.
EBO began changing when I stopped asking what else I could add and started asking whether the product deserved to exist at all.
Accountability can help students remain consistent, but visibility can easily become pressure or surveillance. EBO forced me to think seriously about where that boundary belongs.
Believing that students struggle with consistency does not prove that EBO is the right solution. I’m learning how to search for evidence without turning research into reassurance.
For months, EBO mostly existed as ideas, documents, rough builds, and conversations. I finally built a proper product experience that shows what I’ve actually been trying to make.
I finally started talking to students instead of designing EBO entirely from my own assumptions. Two conversations were nowhere near validation, but they were enough to remind me why building before listening can be dangerous.
EBO was supposed to make studying easier to begin, sustain and return to. The smarter I tried to make it, the more tracking, context and attention it demanded—until the product started contradicting the reason I built it.
AI helps me write the code, but building something still requires ideas, judgment, direction, testing, and responsibility. So what exactly does that make me?