Entrance UG

• Built the payments layer so money and access can never disagree. The server asks the gateway what happened rather than trusting the browser, settlement is idempotent, and an hourly sweep picks up anything that went quiet. 29 payment scenarios cover it and they run before every deploy.
• Shipped four products on one Postgres schema of 100+ tables: timed mock exams, a course library, reading drills and cohort mentorship. Five kinds of user see five different versions of it, and each one is a separate portal.
• Replaced form-by-form content entry with a bulk importer that shows you a dry run first. It spans all four products and now carries 99.7% of a 5,000-question bank.
• Built the API's delivery pipeline on AWS (GitHub Actions → ECR → SSM onto EC2), instrumented it, then cut image build time 40% by caching the dependency layer.
• Ran an authorization sweep that fired every route with credentials that shouldn't open it — wrong role, and right role holding someone else's id. Roughly 1,683 negative cases, and it caught a privilege escalation between two mentors who shared a student.
• Tracked down a cross-user data leak in production caused by two systems that were each working exactly as designed. Closed it with one header and a written invariant.
• Shipped 72+ schema migrations against live student data with no data loss, under a rule that splits every destructive change across two deploys.

Mock tests

Full-length and sectional papers under real exam conditions, with a section clock, a question palette, mark-for-review, auto-save and auto-submit.

Course library

376 lessons organised by subject, topic and subtopic, each with its own practice test.

Daily challenge

A new reading-comprehension passage and data-interpretation set every day, with streaks, a weekly leaderboard and an archive of closed passages.

Mentorship

Cohort batches with an assigned mentor, weekly tasks, live classes, a doubt thread and batch tests.

Five kinds of user, and they each see a different product:

Students

get the four products, a dashboard, their own analysis, bookmarks and a community chat.

Parents

get a read-only view of their own child and nothing else: attendance, tasks, test results.

Mentors

get only the batches assigned to them — roster, tasks, classes, doubts and tests.

Admins

get 43 pages across 16 permission areas that can be granted one at a time.

Everyone else

get a public site with free resources, plan pricing and a sample quiz.

Behind all of that: 295 published tests, a 5,003-question bank, and a 100+ table schema holding it together.

The brief was short to say and large to build. The client wanted their own exam-prep platform: timed mock papers, a course library, daily drills and mentorship in one place, built around the way these exams actually work.

Some things were fixed before I wrote a line.

One developer.

Me. No reviewer, no second pair of eyes, nobody to ask.

A real launch date,

because students were waiting.

A tight monthly budget,

set by the client. That one constraint decided the whole infrastructure.

My first production deployment.

I had never put anything on AWS, never owned a domain, never taken a payment, never had a user I could not just email.

This platform takes money and then has to deliver what the money bought. A bug in a mock test is annoying. A bug in the payment path is somebody’s money.

1. 01

   Build it

   I did not start with code. I started with the database, on paper first and then in a copy of the schema I could throw away — every table, field and relationship, before anything got built on top of a shape I would regret.

   Two decisions came out of that week and both held for the whole project. The first was splitting the platform into four pillars, each owning its own tables, so a feature touches one pillar and a mistake in one cannot corrupt another. The obvious alternative was one attempts table with a type column; I took the duplication on purpose, and paid for it later when the four question tables turned out not to have matching columns.

   The second was that all four pillars share one examination engine. What surrounds a test differs by pillar, but a student sitting a paper should not be able to tell which pillar it belongs to.

2. 02

   Harden it, then launch

   Before taking any real money I went looking for ways the payment path could be wrong. It took two days and turned up eight bugs. One of them let a student renew a plan forever off a single payment. I did not just reason about it — I reproduced it, then fixed it so the arithmetic could not produce that answer again.

   The other half of that fortnight was infrastructure, and it went badly. The plan was AWS App Runner, but AWS had stopped taking new App Runner customers months earlier, so it was not available to this account. Lightsail containers came next; that hung partway through issuing its TLS certificate, stayed stuck for days, could not be deleted, and my support case went unanswered.

   I built it a third time on a plain EC2 instance with Caddy in front, picked specifically because every step of bringing the site up is something I can watch happen from a shell and retry. What made three attempts survivable: nothing in the Dockerfile knows what it is running on, so changing hosts twice cost a deploy workflow rewrite and nothing else.

3. 03

   Run it

   Running software is a different job from writing it, and I did not know that until I was doing it. Within a week students were telling me their dashboard was greeting them by somebody else's name. Nothing was wrong with the API and nothing was wrong with the CDN — the bug lived in the gap between them, so finding it meant thinking about the shape of the deployment rather than reading any code.

   What that month really produced was tooling. I made the deploy record what it costs on every run, because I had noticed a figure in my own documentation was an estimate from watching a screen rather than anything I had measured. I promoted my verification suite from something I ran out of habit to something that gates the deploy and can block a release. And I wrote a workflow that can diagnose the instance and roll it back without me shelling in by hand.

Each one stands alone. Read whichever is relevant to you. The engineering notes go a level deeper on all four.

One I found, one my users found, one the machine found.

500+ students, live payments, 5,003 questions in the bank, 295 published tests and 376 lessons, all of it running on one application instance and one database.

Every piece of that was a decision with a cost attached, and I wrote the costs down.

One instance, one container.

A deploy is a restart, so a deploy that fails to start is an outage until it is fixed or rolled back. That is exactly why there is a rollback workflow. A second instance did not fit the budget, and it is the first thing I would change if availability became a requirement rather than a preference.

The API and database are secured by TLS and credentials rather than network isolation.

I costed a private network and it was declined for launch, because the gateway alone would have roughly doubled the monthly bill. Written down as a decision, with the trigger for revisiting it.

Managed container hosting was costed and declined too.

The load balancer alone costs more than everything else put together. The trigger I wrote down is a second instance becoming necessary, at which point the balancer stops being overhead and becomes the thing I needed anyway.

Background jobs run inside the API process on a timer

rather than in a separate worker. That is correct at one instance, and every write they make is idempotent, which is what would make a second instance safe to add without rewriting them.

No load test yet.

Nobody knows how the submit path behaves when forty students finish a mock in the same minute. It is the next thing I would measure.

• A percentile I was showing students was invented. I removed the metric rather than keep a number that looked impressive and meant nothing.
• I was about to write that I had added code splitting to the React app. It was a fair guess and I nearly wrote it down. One production build showed 50 chunks already there.
• I nearly added a check to my test suite that duplicated one already in it. Padding a test suite is the same mistake as padding a resume.
• I was told the migration count was 73. It is 72. The extra one is a lock file.

That last one is trivial, and that is exactly why it is on the list. The habit is not caring about the big claims. It is checking the small ones, because the small ones are where you stop looking.

Frontend

React 18, TypeScript, Vite, React Router (five separate lazy-loaded route trees), TanStack Query, Tailwind CSS, Recharts, KaTeX for maths in questions

Backend

Node, Express 5, TypeScript, Prisma, Zod for request validation, JWT access and refresh tokens, bcrypt, helmet, rate limiting, compression

Database

PostgreSQL — 100+ tables, 72+ migrations, raw SQL where the query mattered

Infrastructure

AWS — EC2, RDS, S3, CloudFront, ECR, SSM, Secrets Manager, Amplify Hosting. Docker. Caddy terminating TLS with Let's Encrypt certificates it renews itself

CI/CD

GitHub Actions → ECR → SSM. Build, typecheck and the verification suite gate the deploy. Migrations apply when the container starts

Payments

Razorpay — orders, webhooks verified on raw request bytes, refunds, disputes, reconciliation

Other services

Transactional email, SMS phone verification, presigned uploads straight from the browser

Tooling

npm workspaces, TypeScript project references, a 47-module verification suite I wrote

All of the infrastructure was new to me when I started. AWS end to end, Docker, Caddy and certificate management, GitHub Actions, SSM, Razorpay, Prisma, writing migrations that run against live data, and operating anything in production at all. I learned each of them on this project and I am comfortable in all of them now.