Projects

The problem

The main NEETprep app is the production platform, and production work there goes to engineering. There was no place to put a student-facing experiment in front of people who already had an account, and no way to tell whether they used it.

What I built

I built NEETprep Labs myself and shipped it. It is a hub of experimental study products, live, reachable from the main NEETprep app, at neet-compete.pages.dev. Students sign in with their existing NEETprep account; the hub takes the session from the main app. Signed-in students can upvote or downvote each product and send private feedback, which lands in a queue the team works through.

Four products are live on it. NEET Compete is the substantial one: students challenge a friend or get matched into a quick game, and answer timed multiple-choice questions for points based on speed and accuracy. There are friend requests, profiles, ratings, and a question-by-question review of past matches. The front end is React and TypeScript. The back end runs on Cloudflare Workers, with a serverless SQLite database, and Durable Objects holding each game room and coordinating both players over WebSockets. Answers are written as they happen, so a player who disconnects or whose room is evicted comes back to the right state. Players can also play at their own pace instead of waiting on each other. The other three are Recall (spaced-repetition flashcards), NEET Copilot (practice tracking and a chapter study planner), and Time Tracker (study session logging).

I also built the thing that measures it. Each product has its own analytics property. A small collector service does a nightly rollup, and there is an adoption dashboard for the owner. It answers a funnel (hub view, card click, product view, sign-in, first real action), weekly and monthly actives per product, and repeat use per product.

What I'd do differently

I would have defined an active user as someone who completed a real action, from the first dashboard, so backend sync could not inflate the count.

The problem

The people who needed revenue and funnel numbers every morning couldn't write SQL, so they asked whoever knew the warehouse, and answers took a few hours. Two people asking the same question in slightly different words would get different numbers, and then it was unclear which one was correct.

What I built

I built two lanes, which was more work to set up.

The reason to keep them apart is that an agent will eventually invent a number. If people plan around that number, they stop trusting the digest as well. I did not want the digest to grow into a long report covering every possible question.

What I'd do differently

I would show the SQL behind every agent answer from the start. In hindsight, the digest was trusted quickly because it was the same query every morning. The agent took much longer, mostly because people couldn't see how it arrived at an answer.

The problem

We pay for a marketing automation tool that has to be operated by a person, by hand, and it is expensive. As a result, sends went out when someone felt it was time, to an audience that seemed right that day. There was no real cap on how often the same person heard from us. Whether a send had worked was decided afterwards by looking at that week's numbers and telling a story about them.

What I built

An agent runs the channel. I built it because I want to replace the marketing automation tool we pay for. It can learn from what happened, and personalise further than a person setting up campaigns by hand. Who gets a send is defined in SQL, so it is a query someone else can read and disagree with, and frequency caps are enforced in the send path. Every send holds out 10% of the audience, and lift is measured against that control group.

If this were a guideline, I would drop the cap or the holdout the first time I wanted a send out fast.

What I'd do differently

I would make the holdout impossible to turn off. In hindsight, it is the first thing someone drops when they are in a hurry to get a send out, and then you are back to reading the week's numbers and telling a story.

The problem

I query the production database, pull numbers out of web and app analytics and the CRM, draft channel copy, and run push, and I do this over and over. Every AI session started from a blank page, so I was re-explaining the job each time.

What I built

I wrote six skills for those jobs. The copywriting skill drafts ads for Google, Meta and Telegram, retargeting messages (WhatsApp, SMS, RCS), landing pages and push copy, and it reads from a brand-voice reference. The push skill sends and schedules app notifications, and builds journeys and drip campaigns. Of the four that pull numbers, one is a read-only query of the production database for revenue, payments, leads and cohort numbers. Another pulls web and app analytics through the API rather than scraping a dashboard. Another pulls the CRM and the engagement tool and reconciles them. The last reports across the learner database, those analytics sources, the CRM and the engagement tool (revenue, payers, leads, conversions, traffic, channels, engagement).

The rest of the skills in that repo are a fork of a third-party marketing pack. I didn't write them.

What I'd do differently

I would not have forked in a pack of 40+ skills I didn't write. I don't currently know whether anyone uses them, and I suspect a reasonable number have never been invoked.

The problem

Client-side A/B tests flicker, which is a poor experience, and it also biases the result. The hosted tools that do assignment at the edge get expensive fairly quickly at our traffic, so we rationed tests.

What I built

Variant assignment runs on a Cloudflare Worker, at the edge, so there is no flicker. There is conversion logging and a view for results. It runs at about USD 5/month at 200K pageviews a day.

What I'd do differently

I would put an automatic stop for a clearly losing variant into the worker itself. Right now, killing a bad test requires someone to notice it and then ship a deploy.

The problem

The academic team had a large library of source material, and turning exemplar content into exam-ready MCQs took two weeks. The bottleneck was faculty time.

What I built

I prototyped an AI workspace with AI-assisted tools, using 103 source PDFs (textbooks, past papers, chapter importance, question-quality rules, source attribution). There is a companion workflow that takes exemplar content through to MCQs. The academic team uses it as a workflow. I did not write production software here.

What I'd do differently

I would have put a quality gate in at the same time as the speed gains. Faculty will not sign off on the output until the error rate is in a range they trust.

The problem

When the NEET 2025 paper is released, there is a race to publish an answer key, and being out first matters. Students mark themselves against that key, so a wrong answer in it is worse than useless to them. Faculty solving a full paper from scratch is slow.

What I built

I ran several models over the paper and combined their answers into a draft key, within hours of the paper releasing. Faculty reviewed it before anything went out.

What I'd do differently

I would send faculty only the questions where the models disagreed. That is probably the useful signal, and it would have been a better use of their time than reviewing everything.