A commerce platform built from scratch — not a theme, not a template

What was the problem?

A D2C brand on a templated hosted store gives up the two things that matter most: organic search performance, because client-rendered stores are hard for crawlers to read, and operational control, because cancellations, returns and COD collection end up scattered across WhatsApp threads and spreadsheets. Meanwhile the highest-intent data the store collects — its wishlists — sits dormant unless the brand pays for a separate marketing platform.

What we built

Twenty-one server-rendered storefront routes with structured data, an auto-generated sitemap and an editable robots.txt. A nine-state order lifecycle with customer-initiated cancellations and returns, structured reason codes, admin approval with notes and an immutable timeline. Four payment paths including WhatsApp checkout. And twenty-one admin screens across twenty permission-controlled modules covering catalogue, commerce, customers, content, marketing and brand — including a no-code appearance panel that re-skins the entire storefront.

What it does

• Server-side rendered storefront

  Fully-formed HTML for every product, category and blog page.

• Nine-state order lifecycle

  Including customer-initiated cancellations and returns with structured reason codes.

• Server-side total recalculation

  Pricing, tax, shipping, discounts and stock recalculated from the database at checkout.

• Four payment methods

  Razorpay, Cash on Delivery, WhatsApp Checkout and a staging demo mode.

• Multi-variant catalogue

  Size and colour variants with per-option pricing and stock.

• Wishlist campaign engine

  Filtered targeting with per-recipient delivery tracking and campaign history.

• Role-based admin access

  20 modules assignable at read or write level per role.

• No-code appearance system

  11 theme colours, 6 presets, 6 font pairings, logos and favicon.

• Public order tracking

  Order number plus email, no login required.

• Skin-type quiz

  Recommends products from customer answers; questions editable in admin.

• Content engine

  Blog, About and Contact pages and four legal pages, all editable from admin.

• Conversion features

  Cart drawer with upsells, free-shipping threshold progress, coupons and related products.

• PWA install

  Installable with tailored iOS and Android guidance, offline asset caching and install analytics.

• Newsletter and lead capture

  Subscriber lists, branded sends, one-click unsubscribe, and routing to email or webhooks.

What it was built with

• React 18
• TypeScript
• React Router v7
• Tailwind CSS
• shadcn/ui
• Framer Motion
• TanStack Query
• Recharts
• Vite PWA

What changed as a result?

A commerce platform of roughly 39,000 lines of TypeScript across 97 REST endpoints, where the storefront is built to be found and the admin suite is built to be handed over. The brand runs its own catalogue, orders, returns, content, branding and marketing campaigns with no developer dependency.

• Built a server-rendered storefront with structured data, sitemap and editable robots.txt
• Modelled nine order states with an immutable per-order audit trail
• Shipped four payment paths including WhatsApp conversational checkout
• Turned dormant wishlist data into a targeted campaign engine
• Delivered 20 permission-controlled admin modules safe to hand to a growing team

Why does this matter in SaaS & startups?

Most first builds are too large. The useful MVP is the smallest thing that tests whichever assumption would sink the business if it were wrong. Both of our internal SaaS builds — a multi-tenant school portal and a restaurant POS — started as the narrow system one operator needed, then earned their scope.

• Scope that assumes the idea is already validated

  Settings screens, admin tooling and dashboards feel like progress and prove nothing. Building them before anyone has paid is the most common way a runway disappears.

• Multi-tenancy retrofitted too late

  Serving a second customer from a system built for one is an expensive rewrite. Where multiple organisations are clearly coming, tenancy belongs in the first architecture.

• No route to a real user

  A product that exists only on a laptop cannot be tested. Deployment, accounts and access need to work from the first week, not the last.

• Handover that leaves you dependent

  Code you cannot access, hosting in someone else's account and no documentation turn your own product into a negotiation. Ownership from day one avoids that entirely.

More on what we build for SaaS & startups →

See it running