Sai Nandhini Tasty World
A Madurai sweets and bakery brand shipping across India. Next.js 16 storefront and admin, with pack sizes, weight-slab shipping, courier tracking and invoices that generate themselves.
Sai Nandhini Tasty World bakes brownies, cookies and traditional sweets in Madurai and ships them nationally. MnT Future built the whole platform as one Next.js 16 application: the storefront, checkout, order tracking and a full admin back office covering catalogue, orders, inventory, coupons, shipping rates, CMS and analytics. Of the three client platforms on this page it is the one closest in shape to a US D2C brand, and it is built on the stack we use for US work: Next.js 16, React 19 and TypeScript, server components and route handlers.
Food ships by weight
Food that ships is priced by weight, and weight is where most small D2C stores quietly lose money. A brownie box and a plum cake do not cost the same to send to Chennai as to Delhi, and a flat shipping rate either overcharges the near customer or eats the margin on the far one. Beyond that, the brand needed the ordinary things a real store needs and rarely gets from a template: pack sizes as first-class variants, coupons that hold up, an order lifecycle a customer can follow, invoices that do not have to be made by hand, and a back office the owners could run without calling an engineer for a banner change.
A senior-led path from idea to live.
Price shipping the way couriers actually price it
Shipping rates are held per destination as weight slabs, with a rate for each slab and an explicit per-half-kilo rate beyond the last one, plus an estimated delivery time. Checkout resolves the real cost rather than approximating it.
Make the pack size the thing being sold
Products carry units of measure as variants, so a 250g box and a 1kg box are separate sellable things with their own price and their own stock, not a dropdown that the inventory ignores.
Automate the paperwork
An order moving through pending, processing, shipping and delivered sends the customer the right email at each step, and the invoice PDF is generated server-side and attached rather than assembled by a person.
Give the owners the controls
Catalogue, hero carousel, CMS pages, coupons, shipping rates, reviews and global settings are all editable in the admin, so the day-to-day running of the shop never needs a deploy.
What we built
For shoppers
- Catalogue with categories, subcategories and pack-size variants, each with its own price and stock
- Per-product SEO metadata and Cloudinary image galleries
- Cart and wishlist that survive a refresh, with guest checkout available
- Coupons validated server-side at checkout
- Shipping cost resolved from destination and basket weight before payment
- Razorpay checkout with server-side order creation and signature verification
- Order tracking with courier and AWB, and an email at every status change
For the shop owners
- Product master with rich-text descriptions, galleries and featured flags
- Order management across the full lifecycle, with invoice PDFs generated automatically
- Inventory with stock transactions, and low-stock alerts on the dashboard
- Shipping-rate editor: destinations, weight slabs and overflow rate
- Coupon, hero-carousel and CMS-page management
- Sales-trend and revenue analytics built on Mongo aggregation
- Google Places reviews pulled in alongside on-site reviews
- Role separation across customer, staff and admin
What we shipped, on screen.
The storefront
Brownies, cookies, cakes and traditional sweets, presented the way a food brand needs: photography first, with the pack size decided on the product page.
Pack sizes as real variants
Each unit of measure carries its own price and its own stock, so a sold-out 1kg box does not hide the 250g one.
Where the hard problems were.
The decisions that keep a shipping food brand's margin intact and its back office out of a spreadsheet.
Shipping that reflects the courier bill
Weight slabs per destination with an explicit overflow rate, so a heavy order to a far city is priced correctly instead of averaging the margin away.
Pack size is inventory, not a label
Units of measure are variants with their own price and stock, which is what stops a food store overselling its most popular box.
Invoices and emails without a human
Status changes trigger the customer email, and the invoice PDF is rendered server-side and sent, so nobody is assembling documents by hand at the end of a busy day.
The stack we use for US builds
Next.js 16, React 19 and TypeScript with server components and route handlers, which is the same foundation we put under a US D2C platform.
Engineering decisions
Every technology earned its place by solving a specific problem better than the alternatives.
Weight-slab shipping rates per destination
Used for: Each location holds an array of slabs, plus a per-half-kilo rate for anything over the last one and an estimated delivery time.
Advantage: Mirrors how couriers actually bill. It is also the same shape as a US zone-and-weight table, so the model ports without a redesign.
Units of measure as product variants
Used for: Pack sizes are stored as variants carrying their own price and stock rather than as a display option.
Advantage: Stock is tracked at the thing customers actually buy. A pack-size dropdown that shares one stock number will oversell the popular size.
One Next.js app for storefront and admin
Used for: App Router with server components for the shop and route handlers for the API, admin included.
Advantage: One deploy, one auth model, one type system. For a team this size a separate admin service is cost with no benefit.
Server-side invoice rendering
Used for: Puppeteer locally, serverless chromium in production, generating the invoice PDF on order.
Advantage: The document is produced by the same system that owns the order, so it cannot disagree with it.
better-auth with role separation
Used for: Email and password plus Google OAuth, with customer, staff and admin roles.
Advantage: Staff can run orders without holding the keys to settings and payouts, which is the separation a small team forgets until it matters.
What it's built on.
- Next.js 16
- React 19
- TypeScript
- App Router
- MongoDB
- Mongoose
- better-auth
- Razorpay
- Cloudinary
- Tailwind CSS
- Radix UI
- Recharts
- Puppeteer
The questions buyers ask about this build.
Because couriers bill by weight and distance, and a flat rate has to be wrong in one direction. Set it low and every distant order loses money; set it high and nearby customers overpay and abandon. Slabs per destination resolve the real cost at checkout.
Close. The stack is the one we use for US work, and the shape is the same: catalogue with variants, coupons, weight-and-destination shipping, courier tracking, invoice automation and an owner-run back office. A US build swaps Razorpay for Stripe and the Indian courier for a US carrier, then adds the sales-tax engine and the ADA and PCI work we do as standard.
Yes. Product design, the storefront, the checkout, the admin back office and the integrations. Published here with Sai Nandhini Tasty World's permission.
Shipping a physical product nationally?
If your shipping is a flat rate because the real calculation was too hard to build, that is margin leaking on every order. Bring it to a free strategy session and we will size the fix.