ProfitMaster Website

The problem

ProfitMaster runs live financial-education seminars for Telugu-speaking investors, backed by mentors with over two decades of industry experience. They needed a public site to handle seminar registration, payment processing, and blog publishing, with near-zero infrastructure cost during pre-revenue rollout, and a separate admin surface for their content team.

Architecture

Two Next.js apps sharing one Supabase Postgres schema. The public user site runs on Cloudflare Workers at the edge, and the admin dashboard runs on Vercel, chosen over a single-app monolith so the admin surface (higher traffic-per-user, richer UI) could deploy independently from the user site (cache-heavy, edge-served). Both apps read from the shared Postgres via Supabase. Razorpay handles seminar payments with server-authoritative pricing, so the client cannot manipulate transaction amounts. Blog images are stored on Cloudflare R2 with zero egress cost. The admin dashboard writes blog posts and seminar configurations; the user site reads them.

What I owned

The user-facing website on Cloudflare Workers, including page routing, seminar registration flow, blog reading experience, and Razorpay checkout integration. The two-app architecture decision (splitting user site and admin into separate deployments, sharing one Supabase Postgres schema). The Razorpay integration with server-authoritative pricing. The atomic seat reservation logic for live seminar bookings via Postgres functions. End-to-end deployment on Cloudflare Workers. Client engagement, requirement meetings, and delivery timelines through the rollout.

Hardest technical decision

Atomic seat reservation for live seminars. For capped-attendance events, two concurrent bookings could both grab the last seat if the capacity check and pending order insert weren't atomic. Solved this with a Postgres function that performs both operations inside a single transaction, so two parallel booking attempts serialize through the function and can't both succeed. The reservation function is invoked by the checkout API before the Razorpay order is created, so a full event returns a clean "sold out" response instead of failing at payment time.

What I'd do differently

Move seat reservation behind a queue for higher-volume events. The current atomic approach works well at seminar scale (dozens to hundreds of registrations), but wouldn't scale to thousands of concurrent booking attempts without lock contention. Also introduce a preview environment for the Cloudflare Workers deployment; currently, non-trivial changes have to go through staging via git branches, which slows iteration.