Case study
TheFifthCusp
A full astrology-and-spiritual-services platform for FifthCusp — public brand site, ops admin and API — with a polymorphic 8-vertical booking flow, Razorpay checkout and calendar-integrated consultations.
- Role
- Solo full-stack build
- Contract
- ~2 months
- Mode
- solo
- Headline result
- 8 verticals one booking flow
- Live
- Visit site
Context
TheFifthCusp is a spiritual-services practice — astrology, energy work, vastu, manifestation, tarot, numerology, wealth architecture and material remedies. In 2026 they needed to move the business online end-to-end: a brand site people can actually book from, a real ops backend for the practitioners, and payments that don't need a human in the loop. I built the whole thing as their freelance developer.
The problem
Operations were manual — bookings taken over the phone, remedies emailed by hand, no single source of truth for the practitioners' calendar. The public site had to sell eight distinct service verticals and run a checkout on each, publish long-form content (blogs, careers, page-scoped FAQs), and hand off a live booking to a Google-calendar-backed consultation flow. And the admin had to be substantial enough that the practice runs the day-to-day from a browser.
Architecture & solution
Three apps against one Express + MongoDB API. Public site is Next 15 (SSR for the service verticals' SEO), Vanilla Extract + Tailwind, Framer Motion, TanStack Query, Razorpay embedded checkout. Admin is a Vite + React 19 SPA with twenty-two feature areas — services, orders, customers, coupons, blogs, careers, calendar/consultation/remedy events, recurring orders, payment links, testimonials, page-meta SEO, a page CMS, a notepad. Backend is Express + TypeScript + Mongoose with RBAC (admin/manager/employee), JWT access + DB-stored refresh tokens, Razorpay for payments, Google Calendar API for consultation events, Nodemailer for a dozen transactional templates, and node-cron jobs for recurring orders, remedy reminders and stale-payment cleanup. Zod validates every request; envalid refuses to boot without secrets; helmet / cors / hpp / mongo-sanitize / rate-limit / slow-down sit in front.
Key decisions & tradeoffs
One API, two frontends: Next for the marketing surface where SEO on the service verticals matters, Vite for the admin where it doesn't and the build loop is what matters. Polymorphic booking model so a new service vertical is a database entry, not a new route — that decision paid for itself the second vertical in. Admin-only user creation (no public signup) because there are no self-serve users, only staff. DB-persisted refresh tokens so logout and password change actually invalidate sessions instead of pretending to.
Results
Shipped as the live platform at thefifthcusp.com — public brand site with the service verticals wired to Razorpay checkout, and the admin the practice now runs its bookings, orders, remedies and content from. Built solo in roughly two months.
Learnings
The polymorphic service model was the single decision that scaled — the eighth vertical went in as fast as the second. Splitting frameworks between the marketing site and the admin sounds like extra rope until you feel the deploy shapes: SSR-with-cache for the public site vs a static SPA behind auth is enough divergence that keeping them together would be more pain than value. And building a dozen email templates plus a Google-calendar sync early meant the human loop got shorter with every new vertical instead of longer.
Screens
TheFifthCusp home — cosmic purple hero with 'The Fifth Cusp' brand card, tagline 'align with your cosmic destiny', and the eight service verticals across the top nav
// contact
Building something like this?
If this maps to what you're planning, I can walk you through how I'd approach yours.






