Moving Past the Manual Bottleneck

Role: Principal Product Designer / Product Manager

This project started because Build.com had painted itself into a corner. After sixteen years of prioritizing growth over infrastructure, the system for actually running the sites was held together by hand-written markup and SQL statements.

The people responsible for managing thirty different websites were doing it by hand, and it was so fragile that they were regularly crashing the entire network.

The outcome

We built a system called Construct. It moved the company away from manual code updates and into a structured way of managing content. It wasn't just a technical upgrade; it was a recovery of human time.

Recaptured 15 full-time employees. By automating the manual workflows, we saved the equivalent of 15 people's worth of time every year. This wasn't about cutting staff; it was about finally letting those people focus on growth instead of just trying to keep the site online.
Zero site crashes due to merchandising. We eliminated the "human error" factor of hand-written SQL updates. The new system acted as a guardrail, making it impossible to push malformed code to the live sites.
Scaled past $1B in annual revenue. With a merchandising team that was finally optimized and empowered, the business was able to hit a massive financial milestone that had previously been blocked by their own internal bottlenecks.

"The merchandising teams were regularly crashing the sites, not because they weren't capable, but because the system required them to be perfect every single time."

The "hand-written" bottleneck

The deepest problem at Build.com was that every promotion, every banner, and every category update required a merchandiser to stay up until midnight to manually place things on a page using Photoshop and raw HTML.

When I sat down with these teams, I saw people who were exhausted. They were experts in e-commerce, but they were being forced to act like junior developers. Because the work was so manual, they had no time to collaborate or think about strategy. They were just trying to survive the next deployment window. I realized my job wasn't just to build a CMS; it was to build a way for these people to do their actual jobs again.

How we redesigned the workflow

I partnered with a senior developer to rethink the entire process from planning to publication. We decided to ignore the trend of "drag-and-drop" editors and focused instead on extreme deliverability.

We built a system of templates and fields. A merchandiser no longer needed to know how to code a banner; they just needed to fill out a few boxes and choose a style. The system handled the rest. This was early headless architecture—the content was created once and could then travel anywhere, from the web to the native mobile apps.

This approach also saved the native app launch. Right before they were supposed to go live, the app team realized that all existing site content was trapped in HTML and couldn't be read by a phone. Because we had built Construct, we were able to model and deploy over 1,000 records in time for the launch.

"We moved the team from hand-written SQL statements to a system where they could schedule a promotion across 30 sites without ever touching a line of code."

Where I missed the mark early on

In my initial designs, I tried to give the merchandisers too much power. I wanted to make sure they could customize every single pixel. I thought that by giving them total control, I was giving them freedom.

I was wrong. What they actually wanted was safety. Total control just meant more ways to break things. I had to pull back and create more rigid templates. I realized that "limitations" aren't always a bad thing in design; sometimes, a constraint is the only thing that allows a user to move fast with confidence. I had to swallow my pride and simplify the interface until it felt less like a design tool and more like a high-speed engine.

What I'm still thinking about

Construct is still the backbone of the company today, but the next challenge is how to maintain that "startup speed" inside a massive global enterprise. As we scale this architecture across other business units, I’m constantly looking for ways to keep the UI simple enough that a new hire can use it on day one, without needing a weeks-long training course.

"I realized that 'limitations' aren't always a bad thing; sometimes, a constraint is the only thing that allows a user to move fast with confidence."