“Okay, decision made. Let’s get started.”
That was the end of our meeting, but it was also the beginning of something slightly terrifying. Zac Smith, our CEO, had just done what he does best: throw the football down the field.
Now we all had to start running!
To understand the moment, you have to rewind about ten days. Over a weekend, our head of Engineering (Drew) had vibe-coded a simple unified inbox to fit inside our Milo-based operator portal. While it wasn’t fully wired up, it stimulated an important discussion: how can we accelerate progress on the GTM aspects of Milo?
A few of us raised our hands to look into how we might proceed. Should we build everything on our wish list internally? Should we rent key capabilities (such as AI-powered customer success) and only build the most core ones ourselves? Was it worth hiring another engineer to ensure we could actually make progress in a timely manner?
After a week exploring routes and analyzing tradeoffs, we huddled with Zac and Drew. Within minutes, Zac broke the news: we were thinking about it all wrong, and we had to flip the script.
- First off, we weren’t hiring more engineers.
- In fact, the engineering team wouldn’t be building any of what we needed (at least not for now).
- Instead, all of the non-engineers were going to do it.
And despite an obvious lack of software engineering expertise, we were the most qualified people in the company to build this critical and huge set of features.
Why? Because we are the experts at the things we need software to do for us: interpreting fraud and growth signals, PQL’s and SQL’s. Quotes, contracts, order management flows. Customer communications across channels and functions, from within the product to the maddening but necessary interactions around large deal negotiations.
This isn’t as out of left field as it may sound. Over the last few months, our team had experimented with Claude in a number of different ways, and we even formally transitioned one of our core team members to an Applied AI function. After just a few cycles, we are successfully using Claude to automate pieces of our GTM stack, from creating presentations with brand consistency, to ongoing SEO health checks & maintenance, and even auditing our web presence for AI readiness.
While we’ve made significant strides automating through the mundane day to day, Zac rightly put his finger on something bigger: what if we approached our GTM stack with the same intention that our engineering team applies to our product every day?
The hardest part about his steer, however, isn’t the actual building (I should say, at least, I think it won’t be the hardest part). AI has made code creation easier, more accessible and faster than ever. Instead, the biggest challenge will be figuring out how to start, how to govern the work, and how to maintain our work in any sort of production situation. While it’s easy to chat with Claude, our biggest value is in defining an ideal output with that magic combination of clarity, intention and systematic thinking designed to build something genuinely useful.
We’re not simply trying to replicate the tools that we’ve used before with an “ok” outcome. We want to create a GTM tech stack that is truly modern and purpose-built for success. And increasingly, it’s no longer just building the “thing”, it’s thinking through how we use it at scale. We’ll need to build the systems that support our agents to execute on our behalf, with a single human behind the helm, orchestrating and checking their activity.
It is going to take time, and will certainly come with a large learning curve. We’ll burn through more tokens than we know what to do with–Zac already hit his limit shortly after our meeting and had to wait until 7pm to pick it up again–but with the help of both Claude and our Chief Claude Officer (aka our kick a$$ engineering team), we’re confident we’ll be able to vibe our way to a top-tier GTM stack.
And so, welcome to the first post in our series of “the marketing team built this”. We’ll be sharing our architecture decisions, the failed token exchanges, and whatever else we learn along the way. If you’ve built a stack from scratch and have advice on how to approach the architecture (or how not to), we’re all ears.