Zero-to-one is infinite motion.

For the past year, I've been building Ad Manager, a multi-retailer ad-intelligence platform that ingests 100M+ ad records for 600+ brands every day, projected to manage $1B in 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 wanted to take down these Goliaths, and they put me in charge.

I've been with this project since its inception, leading and developing every major aspect of it: data engineering and pipelining, database management, frontend development, backend development, cloud infrastructure management, deployment pipelines, and DevOps.

I've experienced all the growing pains associated with building a product zero-to-one in a startup environment. These 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.