Zero-to-one is infinite motion.

For the past year, I've been building Ad Manager, a multi-retailer ad-intelligence platform that ingests more than 100M ad records for over 600 brands every day and is projected to manage $1B in annual ad spend.

The main value proposition for Ad Manager is that it's a one-stop shop for a brand's ad ecosystem. They can view, manage, and automate their campaigns across all their ad platforms in one view.

Stackline isn't the first to tackle this frontier. Entire organizations were built to provide this service: Pacvue, Skai, CommerceIQ, Flywheel Digital, and Perpetua.

Stackline wants to take down these Goliaths, and they put me in charge.

I started this project from the ground up, designing and architecting its core systems, leading the team responsible for its development, and contributing across every major domain, including product strategy and roadmap planning, data engineering and pipelines, data modeling and database management, frontend and backend development, API integrations, cloud infrastructure, deployment pipelines, DevOps, observability, incident response, and customer support.

Many long nights, weekends, and 500,000 lines of code later, we're just weeks away from releasing the product to the world. Reflecting on this past year, I've experienced many of the growing pains that come with building a product zero-to-one at a startup. Here are a few of them:

• *
  Building a quick, simple solution, enough to get the ball rolling, that fails to handle load or scale. Then having to perform heavy refactors while pushing the product forward.
• *
  As an engineer, fighting for correctness and robustness when leadership wants velocity and sales wants demos.
• *
  Owning decisions and outcomes when structures and processes are ambiguous. "Product owns requirements. Engineering owns implementation. Design owns interactions. Data owns pipelines. Support owns customer issues. Leadership owns priorities." This is all a luxury; I was all of them. Because when product specs are vague and product is swamped on another project, you need to define the requirements and the behavior. When a customer request is really a data-model problem, the abstraction needs to be redesigned. When Z needs to be developed but X and Y are prerequisites, timelines must be sequenced and expectations must be managed. All while pushing the product forward. Because if I didn't step up, no one would, and the product would suffer. And when the product suffers, the team suffers under leadership. That's how I became the lead for the project.
• *
  Some documentation only lives in the mind of an engineer. "Why was it built this way?" "Oh, because we encountered X and Y, leading to Z, and A was the best resolution." Suffice it to say, stricter documentation has been enforced.
• *
  Feeling personally responsible for the success of the product and the team, even when there are forces outside my control: mass layoffs, changing leadership direction, sudden shifts in priorities, and data quality issues.
• *
  The product team extending scope and promoting features as foundational when they are nice-to-haves.

Ad Manager was my identity. This past year, all I ever thought about was Ad Manager. It was my baby. And it was also my hell. It taught me a tremendous amount.

Building something out of nothing is not easy. It's infinite motion, taking seemingly infinite, all-consuming energy. It takes care, resilience, and responsibility.

You need to care deeply enough to do a good job and see things through to the end. Because it's not built until it's built. And even when it is, it's still a work in progress.