Shipping at
Launch Speed.

I've been the frontend developer on Mivi since the beginning. Not "since the redesign" or "since the migration" — since the first product page went live.

Mivi is India's first audio manufacturing tech brand. Bluetooth speakers, earbuds, neckbands, mobile accessories — all designed, manufactured and sold out of India. They're not a reseller with a logo. They make the product. And when I joined the project at Able.do, they were growing faster than any storefront could comfortably keep up with.

The pace

There were days when Mivi would launch three or four products in a single day. Not variants — entirely new products, each with its own specs, its own photography, its own story to tell. And the turnaround? Two days. Sometimes less.

That's the rhythm I built inside for years. A product brief lands, you get the assets, you build the page, you test it, it ships. Then the next one lands. There's no sprint planning for this — there's just a pipeline that either keeps up or doesn't.

Being the frontend developer at that pace means you stop thinking in pages and start thinking in systems. You can't hand-craft every product page when four of them need to exist by Thursday. The system has to do the work, or you drown.

Open source to Apex

The site started on an open-source e-commerce platform. It worked — until it didn't. When you're processing thousands of orders, managing shipping flows, running influencer campaigns, and trying to give each product its own personality on the frontend, the limits of a general-purpose platform start showing up fast.

The team at Able.do had been building a proprietary platform called Apex. Purpose-built for the kind of creative flexibility Mivi's product pages demanded — and the kind of operational scale their backend needed. The migration wasn't a rewrite from scratch. It was more like lifting the entire storefront off one set of rails and setting it down on another, while the store stayed open.

My job was the frontend side of that lift. Rebuilding the component layer, the product page templates, the cart, the checkout flow — all on the new platform — while making sure customers never noticed the switch. The design didn't change. The architecture underneath it did.

The design evolutions

I'd call them evolutions, not redesigns. A redesign implies you throw things away. What happened with Mivi was more organic — each iteration grew out of the last one because the pace demanded it.

The first product pages were bespoke. Custom layouts, hand-placed elements, one-off animations. They looked good, but they took too long to build. When you're shipping three pages a day, "bespoke" is a luxury you can't afford.

So the system evolved. Layouts got componentised. Typography became systematic. Animations turned into reusable patterns instead of one-off flourishes. The design didn't get simpler — it got more disciplined. Every product page still felt distinct, but the bones underneath were shared.

That's the thing about building under pressure: you don't plan a design system, you discover one. Each sprint, each late-night product page, each "we need this live by morning" — they all carved the system into shape. The constraints did the design work that a committee never could.

The frontend stack

The final system — what Mivi runs on today — is a fully custom frontend on the Apex platform. Every piece was built to solve a real problem that showed up at scale:

• A componentised UI library that let each product page feel unique while sharing structure underneath.
• Dynamic product pages the content team could manage without a developer — specs, images, copy, all CMS-driven.
• A live cart and checkout flow that handled flash sale traffic without falling over.
• Transactional mailers — order confirmations, shipping updates, return flows — all templated and branded.
• Mobile-first from day one, because Mivi's customers are largely on mid-range Android devices. If it didn't work on a ₹12,000 phone, it didn't work.

The site serves two languages worth of product content across dozens of SKUs, handles campaigns, discount codes, and influencer attribution — and the content team runs it day-to-day without engineering support. That's the real measure of whether a system works: can the people who aren't developers use it without calling one?

What I learned

Eight years on one product teaches you things that project-hopping doesn't. You see the consequences of your early decisions. You live with the shortcuts. You learn that the component you built in a hurry at 2am is the one you'll be maintaining for the next three years.

The biggest lesson: speed and quality aren't opposites. They're the same discipline. When you have two days to ship a product page, you can't afford to be sloppy — sloppy means rework, and rework means you miss the next launch. The pace forced the code to be clean, the components to be reusable, the system to be predictable. Not because anyone mandated it. Because the alternative was drowning.

What I'd improve next

• Performance audit on the heaviest product pages — image optimisation, lazy loading, bundle analysis.
• Structured data (JSON-LD) for every product — Mivi's search presence could be stronger.
• A shared animation library with reduced-motion support baked in.
• Better preview tooling for the content team — let them see exactly what a page looks like before it goes live.
• Accessibility pass across the full checkout flow — screen readers, keyboard nav, focus management.