A Chosen Son

A Chosen Son is the public practice of Jay Singh Zala, a Gujarat-based astrologer and numerologist. The brief was to move the practice off Instagram DMs and manual UPI screenshots and onto a proper site — service pages, an online checkout, a way to list and sell gemstones, a place to show the studio's art, and an inbox for career and collaboration enquiries. I built and shipped it with one teammate two years ago; it's been live at achosenson.com ever since.

A single astrologer running a dozen different services — consultations by voice call, in-person and video sittings, numerology reports, vastu, meditation programs, gemstone recommendations — needed one site that could describe each one, take a booking with birth details and payment, and let a small team keep the catalogue, blog and art gallery fresh without a developer in the loop. Everything had to work in Indian rupees end-to-end, from tax on the cart line to the receipt in the customer's inbox.

The front end is a Create-React-App (Craco) SPA in a Lerna/Yarn monorepo — a static-site package for the public site and a shared-components package for the design system, both on Chakra UI, Redux Toolkit and React Router 6. The API is an Express service on Node backed by MariaDB through the mariadb driver's connection pool, structured as route → controller → helper. Razorpay handles payments end-to-end: the client asks the API to create an order (with tax and address captured up-front), Razorpay Checkout runs on the browser, and a verification endpoint validates the HMAC signature before writing the order and emailing the receipt through Nodemailer over the studio's Google Workspace account. Art-gallery uploads go through Multer to disk and are re-encoded with Sharp; birth-place coordinates are turned into a timezone with geo-tz so lagna and navamsa charts compute against the right frame.

I picked MariaDB over Mongo because the data is genuinely relational — users, addresses, categories, products, orders, order-items, blog posts, art pieces, careers, consultation slots — and I wanted joins, not embedded documents that quietly drift. The monorepo exists because the shared component library was going to power a second surface (the ecom package) later; splitting it early meant no copy-paste when it landed. Auth is JWT with a separate refresh-token endpoint rather than sessions, so the API stays stateless behind a simple verifyToken middleware. Payments live behind a helper that always creates the Razorpay order server-side and verifies the signature server-side — the client never sees a key that could sign an order on its own. Transactional mail runs on a dedicated hiring/mail config pair rather than one shared transport, so a bounced CV never blocks an order receipt.

Live at achosenson.com since 2024, running the practice's entire online surface — services catalogue, gemstone store, art gallery, blog, career applications with CV upload, and Razorpay-backed checkout in INR with GST. Advertised as a hundred-thousand-plus lives touched, with a 15-day money-back guarantee banner riding above the fold on every route. A separate admin (a Lerna workspace under AChosenSon-Admin) lets the studio manage the catalogue, blog, gallery, careers and orders without touching the codebase.

The one that stuck was that a monolith backed by a real relational database is a perfectly good foundation for a practice-scale product — chasing microservices or a document store here would have been ceremony that slowed shipping and bought nothing. The one I'd change is the way sensitive config was handled early on: keys and mail passwords crept into config files before we tightened everything up to .env, and untangling that later was more work than doing it right on day one. Two years in, the architecture I chose is still what's serving live traffic, which is the honest test.