Building a Microservices Platform for Warehouse Operations at Zulily

If you ever snagged a deal on Zulily, there’s a chance the item that landed on your doorstep was picked, packed, and shipped with the help of software I helped build.

Zulily was a flash sales e-commerce company — think daily deals that rotated fast, with inventory that moved even faster. Behind the scenes, the company operated four distribution centers across the US, each one buzzing with workers using handheld devices to manage the constant churn of products flowing in and out. I was part of the team responsible for the custom warehouse management software that powered those operations, and my job was to rethink how we built and deployed the tools those workers relied on every day.

The Problem: One-Off Apps That Couldn’t Keep Up

When I joined, building a new warehouse tool was a slow and painful process. Each application was essentially built from scratch — its own setup, its own patterns, its own deployment headaches. For a company whose entire business model was built on speed and agility, the software development cycle for warehouse tooling was anything but. New features took months to go from idea to the hands of warehouse associates, and rolling changes across all four distribution centers added even more friction.

The handheld devices our warehouse teams depended on needed a steady stream of new mini applications — tools for receiving inventory, managing picks, handling fulfillment workflows, and more. But the way we were building them just didn’t scale.

The Solution: A Modular Microservices Framework

I designed a modular microservices framework using Node.js and Express that gave us a standardized foundation for building warehouse workflow applications. Instead of every new tool being a snowflake, we now had a consistent architecture that developers could plug into. The framework handled the common concerns — routing, authentication, communication between services, deployment — so that teams could focus on the business logic that actually mattered.

This wasn’t just an architectural nicety. It meant we could deploy new tools across all four distribution centers in a predictable, repeatable way. What used to be a coordination nightmare became a routine release.

On the frontend, I built a reusable React component library and an application shell that served as the container for each mini application running on the handheld devices. The component library gave us a shared visual language and a set of battle-tested UI building blocks tailored to the warehouse environment — think scanners, confirmation dialogs, workflow step indicators, and the like. The application shell handled the scaffolding that every tool needed, so spinning up a new app meant assembling components rather than starting from zero.

The Impact

The results were tangible. Development time for new warehouse tools dropped from months to weeks. Our team could iterate faster, respond to operational needs more quickly, and ship inventory and fulfillment features at a pace that actually matched the speed of the business. When a distribution center needed a new workflow, we could have something in their hands in a fraction of the time it used to take.

It was one of those projects where the right abstraction at the right layer unlocked a genuine multiplier effect for the team. And in a business where margins live and die by warehouse efficiency, that mattered.

Reflections

Working at Zulily taught me a lot about building software for environments that most engineers never think about. Warehouse floors aren’t cushy offices with big monitors and fast Wi-Fi. The tools have to be fast, reliable, and dead simple to use — and the platform underneath has to make it easy to keep shipping improvements without breaking what’s already working. It was a great lesson in the power of good infrastructure and thoughtful abstraction, and it’s an approach I’ve carried with me since.