I wrote up the Miro version as Chapter 17 in my GTM Coding Agents repo. here's why you should check it out
Build to learn, buy to scale.
I still buy tools. I like good tools. But I want to know what I am buying them for.
A lot of GTM stacks are purchased before the workflow is understood, so the tool becomes the strategy. That is how you end up with expensive dashboards and no motion.
Test before you invest.
Hand-roll the ugly version. Run it for one client. See what matters. Then buy or build the part that deserves to scale.
UIs used to block most operators from the underlying system. Now you can direct the build in plain English and inspect the outputs.
You still need taste and judgment to spot when the agent is making things up, when the map is fake-useful, and when the board would actually make a prospect say, "yeah, this is how our GTM should run."
You can run the experiment yourself before turning it into a real internal tool.
Miro is programmable. Docs are programmable. Proposals are programmable.
CRM updates are programmable. Even the handoff from "this person is interested" to "here is the first version of their operating system" can be programmed enough to learn from.
So how does this work in practice you might ask.
The proposal alone is a weak sales artifact because it asks someone to judge a promise.
A working map is better.
Before the pitch gets formal, build a rough version of the client's GTM operating system.
For me that means a Miro board showing lead sources flowing into a database, enrichment, CRM, outreach, content, and measurement.
It can be ugly. It just needs to make the client point at the screen and say "this part is wrong" or "this is exactly the mess."
The useful version also has the week-one checklist, stack doc, API access doc, roadmap, and proposal/agreement generated from the same source.
DocuSeal is interesting here because the signature layer can be another programmable step. Same with open source proposal generators. Same with Miro. Same with docs.
The more I use Claude Code, the more I think GTM builders should treat tools like programmable surfaces.
Miro is a canvas API. Docs are a document API. DocuSeal is a signing workflow. HubSpot is a data model with a UI on top.
Start by programming the workflow once instead of buying the finished system.
Put the client info in a small JSON file: known stack, unknowns, owners, campaign type, current bottlenecks.
Claude Code reads it, creates the Miro board, fills the docs, marks missing fields as NEEDS INPUT, screenshots the board, and tells you what looks broken.
That creates a different first call.
Instead of "here is what we can do for you," it becomes "here is how I think your GTM system currently works. Fix my map."
Better feedback and trust during scoping.
testing out Deep Line over the weekend, hearing great things. Just connected it to Codex. Looking good. We'll have more updates
capping with a question to you guys.
you see building as also a learning experience or buy or die?
catch chapter 17 here https://github.com/shawnla90/gtm-coding-agent/blob/main/chapters/17-client-onboarding-miro-boards.md
Shawn Tenam co founder and CEO @ clearbox "your reddit opportunity inbox"