Case study
Cobrahold
A fitness apparel brand needed a store that understands sizes, drops and cash on delivery. We built the storefront, an admin console and an API that keeps every size, number and rupee straight.
- Client
- Cobrahold - fitness and lifestyle apparel, Kochi
- Scope
- Product, architecture, build, deployment
- Shape
- Three applications, one database, one API
- Stack
- Next.js · NestJS · PostgreSQL · AWS
- Status
- Live
- Website
- cobrahold.com
The brief
Selling tees was the ask. Selling sizes, drops and cash on delivery was the problem.
Cobrahold is a fitness and lifestyle apparel brand from Kochi, making train, street and rest wear for lifters, fighters and everyone in between. Its line runs from tees and compression wear to hoodies and joggers, released in collections, limited drops and numbered collector runs.
A template store would have shown the clothes. It would not keep stock right for every size and colour, number a collector run, charge the correct GST slab on each line, take cash on delivery with its own rules, ship through an Indian courier, or let a customer swap a size a week after delivery.
So we built the brand its own platform: one API that owns every rule, a storefront for customers and an admin console for the team, all clients of that API. It stands on the commerce core we had already proven in production for Nalla Malayalam.
What we built
Three applications, one source of truth.
Each has a different audience and a different way of going wrong. The two front ends hold no business rules, so neither can decide a price, a tax or a stock level on its own.
The storefront
Shop by gender, by category and by mood (train, street, rest), pick a size and colour, and pay by UPI, card or cash on delivery. A Next.js 16 app of twenty-nine screens.
- Size × colour variants, packs and drops
- Phone OTP and Google sign-in
- Track an order, request a size exchange
- Reviews with fit feedback
The admin console
Where products, stock, drops and every order are run, from packing to the courier. A Next.js 16 app of thirty-three screens.
- Variant matrix, packs, inventory history
- Shiprocket labels, pickups, GST invoices
- Drops, coupons, offers, home page editor
- Seven roles, mandatory MFA, audit logs
The API
Owns the database and every business rule, and is the only system that holds a credential. A NestJS 11 service of one hundred and ninety-seven endpoints.
- Prices, GST, stock, payments server-side
- Queues for webhooks, reconciliation, alerts
- WhatsApp and email at every order stage
- Catalogue search on Postgres
Screens
What customers see, and what the brand works in.
The storefront is where customers browse, pick a size, pay and track an order. The console is where the team runs products, stock, drops and shipping.
Engineering
Six decisions that shaped the build.
Every one of these came from how an apparel brand that sells drops, packs and cash-on-delivery orders across India actually behaves, not from a demo checkout.
Start from a commerce core that already works.
Accounts, sessions, payments, stock reservation, orders, coupons, roles, MFA and audit logs are the same problems in every store, and we had already shipped them for Nalla Malayalam.
So Cobrahold began from that proven core. The engineering went where an apparel brand is different: sizes and colours, packs, shipping, GST, cash on delivery, exchanges, drops and a storefront built for the brand.
The last medium in black can only sell once.
In apparel, stock lives in each size and colour, and the popular ones run out first. Reading a stock level and then writing an order is a race, and the last unit is exactly where it gets run.
Checkout locks the inventory rows for every variant in the cart, always in the same order so two checkouts cannot deadlock, and reserves stock inside the same transaction. Database constraints refuse to let reserved stock exceed what is on the shelf.
Packs carry no stock of their own. A three-pack draws from its component tees, so the pack and the single tee can never disagree about what is left.
The browser never decides that an order is paid.
A payment is confirmed only after the API verifies its signature and fetches it again from Razorpay. The amount must match the order to the paisa, and a mismatch is flagged for review instead of being accepted.
Confirming payment is idempotent, so a webhook and a returning customer arriving together still mark the order paid once. A sweep every few minutes catches closed tabs and lost webhooks, and a payment that lands after its reservation expired is either re-reserved or routed to a refund.
A drop is a promise of a number.
Collector pieces are numbered, in runs of a hundred. A number is handed out inside the same transaction that marks the order paid, so two buyers can never hold the same one.
When an order is cancelled its number goes back into a pool, and the next buyer receives it before the counter moves on. Drops also open on a schedule, keep pieces locked until launch, and alert everyone who asked to be notified.
Selling in India is its own specification.
Clothing GST changes with the price, so every line is taxed at its own slab inside a tax-inclusive price. Invoices carry HSN codes and split CGST and SGST from IGST depending on the buyer’s state.
Cash on delivery comes with its own fee, waiver and order ceiling. PIN codes are checked for serviceability before checkout, labels and pickups go through Shiprocket, order updates go out on WhatsApp, and delivered orders can be exchanged for another size within seven days.
An apparel store is still a target.
Cookie-authenticated writes must come from an allowed origin with a same-origin header, and the API rejects any field it does not expect. Logins and one-time passwords are rate limited.
Admins sign in with Argon2id-hashed passwords, lockouts and TOTP MFA, and act through thirty-two permissions grouped into seven roles. In production the API refuses to start with placeholder secrets, open CORS or insecure cookies.
Architecture
How the shape arrived where it did.
A proven core first, then everything an apparel brand needs on top of it, in this order.
A proven core, reshaped
Cobrahold started from the Nalla Malayalam platform, then the book-specific parts were taken out and the apparel model went in: size × colour variants, packs, drops, exchanges and a new storefront.
One API holds the keys
The storefront and the admin are separate applications that only ever talk to the API. The database, Redis, Razorpay, storage, shipping and messaging credentials live in one place.
Fast pages that stay true
Public catalogue reads are cached, and every change to a price, stock level or piece of content invalidates the cache and tells the storefront which pages to rebuild, so the next visitor sees the fresh page.
Images handled once
Uploads are checked against their real file type, then re-encoded to WebP in four sizes with their metadata stripped.
Shipped from CI
Every change runs lint, type checks, unit tests and end-to-end tests against real Postgres and Redis. The API ships as container images tagged with the exact commit.
By the numbers
What that adds up to.
The stack
Chosen to be boring where it matters.
Nothing here is exotic. The interesting work is in the checkout transaction, the payment recovery and the Indian commerce rules, which is where it belongs.
Application
Infrastructure
Services and libraries
In short
Showing tees in a grid is the easy version. The real job was a store that knows every size left on the shelf, numbers every collector piece once, and gets the GST right on every line.