Layered Living

context

A client (Shankar Plywood House) needed a real online store for furniture, lighting and decor, not a template demo but an actual business that takes money. The brand is editorial and ultra-minimal: print-magazine whitespace, strict greyscale, a type-weight ceiling of 500, no shadows. That aesthetic was a hard constraint enforced in code, not a coat of paint.

the problem

E-commerce is deceptively deep: a catalog non-engineers can edit, authenticated checkout, payments that can never double-charge or under-charge, tax-compliant invoices, and transactional email, all of it correct under real users and real money.

what i built

A clean split between two backends with no cross-contamination: Sanity4 owns the catalog and editorial content; Supabase5 owns everything user-related (auth, cart, orders) behind row-level security. Money is integer paise across every boundary. The type system is the first defence against unit bugs.

1. 1.

   Crash-safe, exactly-once orders via an idempotent Postgres RPC called by both the browser and a Razorpay6 webhook safety-net

2. 2.

   GST-compliant PDF invoices with atomic per-year sequential numbering, generated server-side and emailed on payment

3. 3.

   Razorpay6 payments verified server-side with constant-time HMAC-SHA256, so the client never sees a trusted amount

4. 4.

   Optimistic Zustand cart over a Supabase5 source of truth, reconciled via realtime

5. 5.

   Centrally SEO-instrumented: JSON-LD, a 160-URL ISR sitemap, dynamic OG images

outcome

Live at layeredliving.co.in, serving a real storefront end to end. Security was a first-class deliverable: RLS on every user table, distributed rate-limiting via Upstash Redis, DPDPA-compliant cookie-gated analytics.

context

A client who sells furniture, lighting and decor wanted a genuine online shop rather than a demonstration, with customers actually paying. They also wanted it to look like a printed magazine: a lot of white space, no colour, nothing bold or shiny anywhere. That was written into the code as a rule, not painted on afterwards.

the problem

Selling things online is deeper than it looks. Someone who is not an engineer has to be able to add a product. People have to be able to sign in. The payment must never charge twice, and never charge the wrong amount. The invoice has to satisfy the tax office. The confirmation email has to arrive. And every one of those has to stay correct with real customers and real money going through it.

what i built

Two separate systems that never touch each other’s business: one holds the products and the words, the other holds everything belonging to a customer, their sign-in, their basket, their orders, sealed so nobody can read anyone else’s. Prices are stored as whole paise rather than as decimals, because decimals are how shops accidentally give things away.

1. 1.

   A sale is recorded exactly once, even if the payment page dies halfway through. The browser reports it and the bank reports it independently, and the shop still counts one order.

2. 2.

   Tax invoices are produced as PDFs and emailed the moment the payment lands, numbered in an unbroken run for the year, with no gaps and no repeats.

3. 3.

   The payment is checked on the shop’s own server against the bank’s signature, so a customer who edits the price in their browser gets precisely nowhere.

4. 4.

   The basket updates the instant you click and then quietly agrees itself with the real record, so it feels immediate without ever lying about what is in it.

5. 5.

   Everything a search engine needs is generated rather than written: a 160-page map of the site, structured descriptions, and a share image for each product.

outcome

It is live and running a real shop from end to end. Security was part of the build rather than a pass at the end: each customer’s data is sealed off from every other customer’s by the database itself, abusive traffic is throttled, and nothing is measured about a visitor until they agree to it.