Uniprep

Overview

UniPrep is a preparation platform for the Common University Entrance Test, the exam Indian students sit for undergraduate admission to central universities. Our client came to us with a specific commercial goal rather than a vague brief: they wanted to sell CUET courses and mock tests directly to students, without routing the business through a third-party marketplace that takes a cut of every sale and owns the customer relationship.

That meant the site could not stop at marketing. It had to handle the whole loop: a student discovers a course, pays for it, gets access immediately, and comes back to study and test themselves.

The Brief

The work split into three deliverables that had to fit together.

The student experience. A catalogue of CUET courses and mock tests that students could browse and understand before paying, designed from scratch rather than adapted from a template, plus accounts and access control so paid content unlocks for the buyer and stays closed to everyone else.

Payment collection. Razorpay integration handling the money, on the payment methods Indian students actually use.

A CMS admin panel. A dedicated back office where the client creates and manages mock tests, questions, and course content themselves. This was not an afterthought: an exam preparation business lives or dies on how quickly it can publish new material, and every question that needs a developer to go live is a bottleneck on the business.

Underneath all of it sat a constraint worth naming: this is a business finding its audience, not an established one. Running costs had to stay low in the early months.

Approach

We picked the stack around those constraints rather than around novelty.

Razorpay for payments. Indian students pay by UPI far more than by card. A checkout that leads with UPI and supports netbanking and wallets converts substantially better here than an international gateway, and Razorpay settles in rupees without foreign exchange friction for the client.

Supabase for accounts and data. Authentication, the course and question data, and the record of who has purchased what all live in one place. Its row-level security model was the deciding factor: access rules for paid content are enforced at the database, not merely hidden in the interface, so a student cannot reach content they have not bought by manipulating the client.

Next.js for the front end. Marketing and catalogue pages render on the server so they can be indexed by search engines, which matters when students find preparation material by searching. The study and test areas behave like an application behind login.

Mobile first, without apology. The majority of students in this market study on a phone, often on patchy mobile data. Every layout decision started at the small screen, including the test interface, which is the hardest part to get right at that size.

Solution

The purchase flow is the spine of the product. A student browses the catalogue, opens a course or mock test bundle, and pays through Razorpay. On successful payment, an entitlement is written against their account and the content unlocks immediately. There is no manual step and no waiting for someone to grant access, which matters because students buy at all hours, frequently the night before they intend to start.

The mock test experience was built to rehearse the real thing: timed sittings, question navigation, the ability to move between questions rather than being forced forward, and a result view at the end that shows a student where they actually stand. Practice that does not resemble the exam builds false confidence, so the closer the format sits to the real paper, the more the practice is worth.

Course content is organised by topic so students can work to their weak areas instead of moving through material linearly, and progress is tracked so returning to the platform after a gap does not mean losing your place.

The Admin Panel

Off-the-shelf content systems are built around articles and pages. A mock test is a different shape: a paper contains sections, sections contain questions, each question carries multiple options with one marked correct, and the whole thing has a duration and a marking scheme attached. Forcing that into a generic CMS produces a data model the client has to fight every time they add a paper.

So we built the admin panel around the actual objects the business works with. The client can create a mock test, add questions to it with their options and correct answers, organise material by subject and topic, and publish when it is ready. Course and catalogue content is managed the same way, which means pricing and descriptions can change without a deployment.

The design goal here was not visual: it was that a non-technical person could sit down and author a full mock paper without instructions, and without being able to put the platform into a broken state. Ownership of the content is what makes the business independent of us, which is the outcome worth engineering for.

Challenges

Payment reliability is not optional. When a student pays and the content does not unlock, you have taken money and delivered nothing, and in this market that costs you the customer permanently. Payment confirmation had to be handled server side through Razorpay's verification rather than trusting a redirect back from the browser, so that a dropped connection or a closed tab after payment still results in access being granted.

Enforcing paid access properly. The naive approach is to hide locked content in the interface, which stops nobody who opens developer tools. Entitlements are checked where the data is served, so an unpaid account gets nothing back regardless of what the client asks for.

Test taking on a small screen. A timed test on a phone has to show the question, the options, the timer, and a way to move between questions, all without the student losing their place or accidentally submitting. This took the most design iteration of anything in the build, because every element competes for the same limited space and none of them can be dropped.

Learnings

For a business selling knowledge directly, the checkout is the product. A student's opinion of the platform is set in the sixty seconds between deciding to buy and getting access, and no amount of polish elsewhere compensates for friction at that moment.

Choosing infrastructure around the client's actual situation, not around what is technically interesting, is what keeps an early-stage product alive. A managed database and a hosted payment gateway meant no servers to maintain and costs that scale with revenue rather than ahead of it.

Building the admin panel properly was the decision with the longest tail. It cost more up front than wiring the content in directly, and it is the reason the client can run and grow the platform without us in the loop. For a content business, the tool that produces the content matters as much as the storefront that sells it.

The wider lesson was about market specificity. Paying by UPI, studying on a phone, revising in short bursts on unreliable data: these are not edge cases for Indian students, they are the normal case. Building for them directly produced a better product than adapting a Western EdTech template ever would have.