I Built the Tool I Needed.
Turns Out Everyone Needed It.

It started the same way every bad decision starts — late at night, way behind on assignments, watching my friends' Snapchat stories while I was stuck on my seventh consecutive McGraw Hill SmartBook module. Everyone was out. I was on question 34 of 80 in a chapter I had already read twice. I wasn't learning anything. I was just clicking.

I remember thinking: "This isn't education. This is data entry." McGraw Hill wasn't testing whether I understood the material. It was testing whether I had the patience to click through an 80-question module at 11 PM on a Thursday. I had a 3.8 GPA. I understood the material. But if I skipped the module, my participation grade dropped. So I clicked.

That night I opened Chrome DevTools for the first time with a mission. I wanted to understand how SmartBook knew which answer I selected, how it tracked my time on each question, and whether there was any behavioral data being collected. There was — a lot of it. McGraw Hill tracks mouse paths, time-on-page, click coordinates, focus state, keystroke patterns, even scroll velocity on reading assignments. It builds a behavioral fingerprint for every student.

So I didn't just build something that could answer questions. I built something that could assist with questions the way a real student would — adaptive, natural, and genuinely useful. That took months. I failed probably fifty different approaches before the first version actually worked end-to-end on a real module with realistic session engagement patterns.

Version 1 was rough. It answered questions. It had no mouse movement, no timing variation, no engagement features. But it worked well enough that I started sharing it with people in my study group. Within a week, five people were using it. Within a month, thirty. Someone put it in a nursing student Discord and it reached 200 people overnight. That's when I realized this wasn't a personal tool anymore.

Every version after that was built from real feedback. A nursing student told me the bot was answering dosage calculation questions in 3 seconds — the same speed as a vocab question — and she was worried it looked wrong. That became Complexity Scaling. Someone's roommate walked in mid-session and she needed to dismiss the interface fast. That became the quick-clear feature. A guy doing his modules at the gym wanted Discord pings. That became Progress Webhooks. Every single feature in SmarterBook v2.8 exists because a real student needed it.

The hardest part wasn't the code. It was caring about the details no one would ever see — the subtle jitter on the confidence button, the micro-variation in how long the bot "reads" a paragraph before scrolling, the way it occasionally hovers over the wrong answer before clicking the right one. Those details are invisible to the user. They're not invisible to engagement analytics. They're the difference between a session that looks human and one that looks automated.

Today SmarterBook is used by students across every major, in every state, from community colleges to R1 universities. Nursing students. Pre-med. Business. Engineering. Education. Every one of them found SmarterBook the same way — they were exhausted, behind, and doing work that wasn't teaching them anything. SmarterBook didn't give them a free pass on understanding the material. It gave them their time back to actually study, sleep, or just be 20 years old for a night.

I'm still the only developer. I still read every support ticket. I still push updates when McGraw Hill changes something. This is a one-person operation built on the belief that the most important thing isn't speed — it's building something that actually reflects how students study. SmarterBook was built to be genuinely useful. And so far, students agree.

— Nillakami, Founder & Developer