How I Grew Dev Tool Signups 71% in 90 Days

Sign Up

Tessa Kriesel

Subscribe to New Posts

Subscribe

In my first 90 days at Tabstack, signups went up 71%. I didn’t get there by running a pile of campaigns. I got there by building software.<br>I market developer tools, and I’ve been writing code since 2006. That combination changes how I work. Where a lot of marketers open a campaign calendar, I open my terminal. I treat go-to-market like an engineering problem: understand the system, build it, ship it, measure it, then make it better.<br>Here’s exactly what I did, week by week, and the play you can take from each one.<br>Before Day One: I Built on the Product First<br>The best decision I made happened before my first day.<br>Once I accepted the offer, I built a real product on Tabstack’s API. It’s called Rival, an open-source competitive-intelligence app that tracks everything a competitor does in public: pricing, hiring, product changes, positioning, reviews, GitHub activity, and it runs full cited research on demand, then tells you what actually changed and uses all five of Tabstack’s endpoints.<br>I do this kind of thing with every developer product I take on. I want to understand the product I'm marketing. So I built, and ran a full developer-experience audit while I built Rival, logging every rough edge I hit. Developers are the audience. I wanted the developer experience improved before I sent more developers there.<br>Rival actually serves multiple purposes. It’s a test surface for the product. It’s a competitive-intelligence tool I use every day. And it’s a distribution play: it’s open source, self-hosting it requires a Tabstack API key, and I had the campaign to get it in front of developers planned before I ever started.<br>The play: use the product yourself, at real depth, before you market it. Build something real with it, not a click-through demo, so you understand what you're actually marketing and you catch the gaps early, before your users hit them. If you're not a coder, try Claude code or other coding agents, they're quite good. Your developers will thank you.<br>Rival is open source. You can try the live demo or dig into the code.<br>Week One: I Stood Up My Systems Before I Ran Any Marketing<br>I came in already knowing the product and the direction I wanted to take, so I started with systems, not deliverables. I built our GTM Command Center, the hub the whole operation would run on, so a single change to our positioning reaches everything downstream. And I stood up our CRM under a real constraint: at Mozilla, consent is off by default and we collect almost nothing unless the user says yes, so I can’t lean on behavioral tracking to understand who signs up. My CRM works entirely from public data instead, respectful by design. The Mozilla way.<br>I'd done this before. I ran a developer GTM agency before Tabstack, so I came in with a playbook, not a blank page. These systems are that playbook, built for Tabstack.<br>The play: don’t start with campaigns. Start with the infrastructure that makes every campaign easier to run.<br>Week Two: I Turned the Docs Gap Into a System<br>When you actually build on a developer product, its problems announce themselves. A setup step fails silently. The docs skip the exact case you just hit. The messaging never quite says what the thing does. We had all of it, and I refuse to send a developer to a bad developer experience, so I fixed ours before I drove anyone to it. Since I’m a team of one, I didn’t rewrite the docs myself. I built a system, trained deeply on Tabstack: a skill for each kind of doc, a knowledge base of the product, review steps that check every claim against the live API, and a pipeline that drafts and opens a pull request for me to approve.<br>It wrote 45 docs in a single day, across half a dozen pull requests, that needed only light polish.<br>This is how I work: I build a system to solve the problem, then keep improving it as I use it. For a team of one, that's the best way to scale. The one I wrote for docs writes my marketing content now, too.<br>The play: never send a developer to a bad developer experience. Marketing only gets a developer to the door. The developer experience decides whether they stay, and developers judge it fast and rarely give it a second look. That makes DX a prerequisite for marketing, not a parallel track. So fix the docs, the messaging, and the setup that fails silently before you drive anyone to them. And fix them with a system, not a one-off, so they hold as the product keeps changing.<br>Week Three: I Did the Strategic Work, Then Placed the Bets<br>Leadership wanted to put money into marketing earlier than I’m normally ready to make bets on. Early or not, I wasn't going to spend it on a guess. So I started with the questions that actually matter.<br>What does this product need to succeed? How do we stand apart from everyone else fetching web data? What pays off this month, what compounds over multiple quarters, and how do I fund both at once?<br>The answer was five...