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.
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.
Here’s exactly what I did, week by week, and the play you can take from each one.
Before Day One: I Built on the Product First
The best decision I made happened before my first day.
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.
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.
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.
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.
Rival is open source. You can try the live demo or dig into the code.
Week One: I Stood Up My Systems Before I Ran Any Marketing
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.
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.
The play: don’t start with campaigns. Start with the infrastructure that makes every campaign easier to run.
Week Two: I Turned the Docs Gap Into a System
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.
It wrote 45 docs in a single day, across half a dozen pull requests, that needed only light polish.
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.
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.
Week Three: I Did the Strategic Work, Then Placed the Bets
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.
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?
The answer was five bets, each one tied to how developers actually find and adopt tools: showing up in the tools they already use, a public schema library where every use case becomes its own discoverable entry point, content built to be found by the AI models developers now ask, brand and marketing execution, and field and community distribution.
The play: do the strategic work before you spend a dollar. Understand the market, define what you are and how you differ, then make a short list of bets that balance quick wins against longer plays that compound. The best opportunities will make themselves known this way.
Week Four: I Launched by Day 24, With the Data Dashboard First
By day 24, we had our first Product Hunt launch live.
Product Hunt was deliberate, and not for the obvious reason that developers are there. It’s a source the AI models trust, so a launch doubles as training signal for the assistants developers now ask. I also have a track record there, which buys speed. I planned and launched this one in a few days. Early, trusted, and fast to run was exactly the profile I wanted for a first move.
Two days before it went live, I stood up our first metrics dashboard across the whole developer journey, API usage, activation funnel, time to value, playground to production, so the moment traffic hit I could see what it did, not just that it showed up. Instrument before you ship, or the launch is noise you can’t learn from.
The play: early on, ship one real growth effort, and choose it by impact. You’ll have a hundred things you could do. The discipline is picking the one that drives the most growth right now and getting it out, while the longer-term work keeps moving in parallel.
Weeks Five and Six: I Built an Agent to Scale Myself, Not to Replace Myself
There’s too much for one person to track. Competitors, community, prospects, sponsorships, content, events. So I built a go-to-market agent, on the open-source Hermes framework, to take the repetitive gathering off my plate.
The agent runs the recurring jobs on a schedule. Daily competitive-intelligence digests. Community listening across Hacker News, Reddit, GitHub, and more. Prospect signals from our CRM. Prospecting batches. Sponsorship research. A social pipeline with MentionDrop. Event-prep briefs. It commits its reports and pings me.
Here’s a concrete one. Rival already runs a cron every night, pulling competitor updates and pushing them into the GTM Command Center. The agent picks that up and synthesizes it, so instead of reading raw diffs every morning, I get the read that actually matters.
The agent gathers and drafts. I read every report, make the call, and do the work. The system makes me faster. It does not replace me. That distinction is the whole reason it works: I get leverage without giving up a single decision.
The play: use AI to scale yourself. There is always more GTM work than one person can do by hand, so hand the repetitive gathering to an agent and keep your hours for judgment and action. One person can run a full operation this way. The leverage is real, and every decision stays yours.
Week Seven: The Machine Started Pumping
This was the inflection point. The daily reports turned on, and the systems started feeding me fresh intelligence every morning instead of me hunting for it.
Two things made it click. First, I wired the systems together: the agent could now read and write the CRM directly, and the GTM Command Center held the single source of positioning that fed everything else. Second, I built the operating layer that gives all that daily output somewhere to go, a content calendar and backlog, a distribution system, and outreach lists pulled from my own network of thousands of contacts.
The play: this is where the work starts compounding. Once your systems connect and feed you output, the job flips from setting the machine up to running on what it produces, and every new problem is easier to solve because the system to handle it is already there.
Week Eight: I Turned Product Hunt Into an Engine
Our second launch, Web Research, went out about a month after the first. From there they came almost weekly, on purpose. A launch every week is a forcing function, and the amount of work behind a single one is the part people underestimate: the positioning and messaging, the website work itself (product pages designed and built, homepage and navigation updates, the SEO and discoverability layer), a working demo, images and launch cards, a video, the Product Hunt listing and maker comment, forum posts, social, a launch email, and answering every question in the thread on the day. The fixed deadline is what gets all of it out the door, week after week.
I already knew the whole site needed a rebuild. I didn’t wait for it. I designed and built a focused product page for this launch myself, so we had something strong to land on now, and left the full rebuild for later.
The play: don’t wait for perfect resourcing to move. Ship a focused page instead of blocking on a full redo, an agency, or a designer, and own your launch surface end to end. Then put yourself on a cadence and let it do the forcing. Nothing gets work out the door like a deadline you committed to.
Week Nine: I Rebuilt the Whole Website Presence in a Weekend
I knew from early on the site needed a full facelift. The old homepage was a single page, and it was weak. Developers couldn’t tell what Tabstack did or didn’t do.
But I didn’t rebuild the whole site first. I did higher-leverage work and waited. When our research page shipped as a one-off landing page with a new design, it set the standard the rest of the site had to meet. So the facelift happened between launches: the product pages, the homepage relaunch, and the search-visibility layer underneath it, llms.txt, per-page structured data, canonicals, a branded 404, a clean sitemap, so the models developers ask can actually find us. Each launch got a stronger surface to land on, and the presence kept improving without ever blocking a launch.
The play: improve your GTM presence, but sequence it. Recognize the big investment early, then hold off until it’s the highest-leverage move instead of the urgent one. Let one strong page set the design and messaging standard, then roll the rest out between launches, so your presence keeps getting better without ever blocking one.
Week Ten: I Reinvested in the Systems & Data
I pulled the whole operation into one terminal workspace with memory, so I start every session already in context instead of re-explaining myself. And I improved the data. With consent off by default and nothing collected unless you allow it, reliable attribution is genuinely hard, so I made it work within that limit, keeping referrer and UTM data through the consent step instead of losing it. A better workspace makes me faster. Fuller data makes every decision better. I do everything in here from ad copy, to email outreach drafts, to building agent skills. It empowers me to do everything within the defined system.
This is also the week I turned on our first paid spend, a TLDR newsletter placement, and not a day before. I waited until the site and the developer experience were good enough that the traffic would land on something ready.
The play: reinvest in your own systems and your data as you go. Efficiency and better information both compound. And don’t buy traffic until you’ve built something worth sending it to.
Week Eleven: The Systems Started Paying Me Back
By now, running go-to-market like an engineer had a feel to it. Every time I hit a wall, I solved it for good.
I’d made launch images by hand for three launches, hours each in Claude Design, so I built a helper that renders them on brand in minutes. My next launch’s imagery took me minutes. I planned a ten-category schema library and had the agent build it in a single overnight batch while I reviewed and shipped it in the morning, weeks of work done in hours. And I measured it hard: a four-launch traffic comparison, a growth report going back to April, attribution diagnostics, a case-study shortlist of our most-engaged orgs, and an exec narrative packaged into a deck.
I’m not doing less. The more my systems handle, the more I get to take on, well beyond what one person could carry alone.
The play: solve every hurdle once. Feel the pain a couple of times, then build the thing that removes it for good, a tool that turns hours of design work into minutes, an agent that runs an overnight build while you sleep. Each fix makes the next thing easier, and easier is what lets one person do the work of a team. That is what running go-to-market like an engineer actually buys you.
Week Twelve: Not Every Launch Is a Tentpole
Our fifth launch, Schema Source, was a quick one. It put eyes on the schema source tool our team built and the schema library of pre-defined schemas my agent built and kept the cadence alive without a heavy lift.
The rest of the week went to the work that doesn’t announce itself. I integrated a fresh positioning pass so our message stayed sharp as we grew, and I got the Browser Automation launch copy ready for the next week, keeping it strictly to what was actually shipping, because overselling a developer tool costs you the moment someone tries it.
The play: not every launch has to be a tentpole. A quick, light launch off something you already shipped keeps the cadence alive and puts eyes on an asset, without the heavy lift of a marquee release. The cadence is the engine. Sometimes you just feed it with what you already have.
Week Thirteen: Final Push before Day 90
Week thirteen ran hard. The sixth launch, Browser Automation, went out with its announcement email. I shipped a competitor-brief tool, and finished the CRM enrichment layer that turns an email into a cited public profile on Tabstack’s own research endpoint. Even then I kept tuning the systems, because at day 90 I’m still sharpening them.
Then I measured my own 90 days the same way I measure a launch. Here’s what the systems produced:
- Signups up 71%
- Activation up 29%
- API requests up almost 6x
- Website traffic up 129%
- Around 1,096 commits
- 29,938 Tabstack API calls of my own, the heaviest usage on the platform
Tabstack is one tool in my stack, but it earns its spot. Rival is built entirely on it. Here’s a small example of why. I wanted to pull a recipe off a page and get clean, structured JSON back for a blog. I asked Claude to just do it, and it failed. Then I had it call Tabstack, and the data came back in seconds, structured exactly the way I needed and exactly what the model couldn’t produce on its own.
The Bottom Line
I grew signups 71% in 90 days by building the systems that made me faster. Work smarter, not harder.
If you market a developer tool, or you’re a developer thinking about marketing your own, here’s the whole thing in one breath. Learn the product by building on it. Fix the developer experience, and build the system that keeps it fixed. Turn launches into a cadence, and never launch without your data ready. Use AI to scale yourself without handing over the judgment. And solve every hurdle once.
You don’t have to be an engineer to run go-to-market this way. It just helps to think like one. I’m a marketer for developers because I’m a developer, and after 90 days I’m more sure than ever that’s the advantage.
If you’re building agents that need to read the live web, Tabstack is worth a look. Grab an API key.
Everything I Built and Shipped
If you want the action behind the playbook, here’s the full body of work from the quarter.
The systems (the machine everything runs on)
- Rival: an open-source competitive-intelligence app on all five Tabstack endpoints: multi-surface scanning (homepage, pricing, blog, changelog, reviews, profile), AI-generated diffs, on-demand cited research, a positioning matrix, threat scoring, a public streaming demo, nightly pushes into the GTM Command Center, and its own MCP server. Open-sourced.
- GTM Command Center: the hub the whole operation runs on: versioned positioning and product context, AI work sessions (strategy, creation, feedback, analysis, optimization), a campaigns module with an AI brief generator, a versioned content and artifact library with SEO/OG and distribution, customer-research ingestion (themes, sentiment, quotes), performance logging that proposes updates back to the context, live metric connectors (PostHog, GA4, EthicalAds), a campaign-performance dashboard, team management, notifications, magic-link auth with domain gating, and an MCP server every other system reads and writes to.
- Tabstack CRM: public-data-only enrichment and ICP scoring, an identity pass (Gravatar, GitHub, npm, PyPI, Slack), a source-linked signal feed, a prospect and account pipeline, funnel-stage imports, and a hosted MCP server. Later moved to Airtable with a trace-based enrichment pipeline.
- GTM agent: built on the open-source Hermes framework: recurring competitive-intel, community-listening, prospecting, sponsorship, and social jobs, network intelligence, publishing integrations, and a Telegram interface. It gathers and drafts; I decide and act.
- Tabstack OS: one terminal workspace with memory: a state-of-work brain, session briefings, reference-repo sync, and a portable knowledge mirror.
- The tech-writing and blog-authoring system: a skill per doc type, a product knowledge base, accuracy-checking review agents, and a draft-to-pull-request pipeline.
Skills, subagents, and commands I built
- Custom skills: api-docs, tech-writing, changelog, readme-writer, tabstack-sdk, blog-author, external-publication-editor, sdk-sync, quiver-publish, product-marketing, vbf-messaging, competitor-profiling, state-of-work, crm-import, writing-clearly-and-concisely, plus a mirrored marketing-skills pack
- Review subagents: api-reviewer, docs-reviewer, readme-writer
- Slash commands for the doc and publishing workflows
Marketing website (built and rebuilt)
- Four product pages: structured extraction, browser automation, web research, and competitive intelligence, with hero demos and real token-cost visuals
- A full homepage relaunch (dark nav and footer, Stack mega-menu) and a blog redesign
- A Developer Hub / resources overhaul and a Use Cases section
- Attribution plumbing: referral/UTM passthrough into signup CTAs, entry referrer/UTMs retained across the cookie-consent delay, and internal links de-tagged
- Consent-gated web analytics
- AI-search visibility: llms.txt and llms-full.txt, per-page JSON-LD, canonicals, keyword-targeted meta titles, a branded 404, a clean sitemap, and legacy redirects
- A consistent UTM + GA taxonomy across every CTA, an accessibility pass, and a font migration to the Mozilla brand faces
Docs
- 45 docs in a single day
- The Interactive Mode set (quickstart, guides, launch post) and an accuracy pass
- Per-endpoint API references (extract/json, extract/markdown, generate/json, automate, research)
- Quickstarts (first extraction, interactive mode, research)
- Seven how-to guides (effort levels, geotargeting, schema design, streaming, production reliability, integrations, LangChain)
- A 14-page comparisons section and SDK-first rewrites
- A changelog page covering SDK 2.0.0–2.6.1
- Ongoing docs work from DevRel: error reference, research guide, a generate-vs-extract page, production rate limits, a full docs audit, and single-source changelog data
- The Tabstack CLI (built by DevRel, hardened to launch-ready, with a schema-pull command and install script)
- A public vertical schema library, ten categories built in a single overnight batch, plus a competitor-profile schema
- A competitor-brief demo app spanning all five endpoints (an 11-section streaming brief with a two-URL positioning comparison)
Product Hunt launches (six)
- Six launches: the first Tabstack launch, then Web Research, Structured Extraction, Dev Tools, Schema Source, and Browser Automation
- For each one: positioning, messaging, taglines, the listing and maker comment, ten forum posts, a launch email, and answering questions in the thread on the day
- A reusable Product Hunt image helper (on-brand launch cards in minutes), launch-day sentiment analysis, and launch-history + launch-comparison research
- Launch videos by DevRel
GTM intelligence and reporting
- Daily competitive-intel, community-signal, and CRM-signal reports; weekly competitive summaries, account intelligence, prospecting, sponsorship, social, and events reports
- A four-launch traffic comparison, a growth report since April, attribution diagnostics, an engaged-orgs case-study shortlist with pre-filled briefs, and an exec growth narrative with a slide deck
Content
- A dozen technical blog drafts, personal-voice and brand voice profiles, a monthly content calendar, a distribution system, and a 30-post backlog
Positioning and messaging
- A five-bet growth investment plan, a VBF messaging framework, six audience micro-segments, a jobs-to-be-done framework, exec and company one-pagers, and a full positioning integration that leans on Mozilla’s trust and privacy stance (ephemeral processing, no training on your data, privacy by default)
Specs and plans
- Design specs and implementation plans for the blog-author system, the Tabstack OS workspace, the using-Tabstack skill, the competitive-intelligence sales page, and the competitor-brief tool
Analytics and dashboards
- Three PostHog dashboards (GTM Metrics, live Launch Day, and Growth/Attribution/Signups) with 36 insights
- The GTM Command Center’s own campaign-performance dashboard, pulling spend and metrics from PostHog, GA4, and EthicalAds to show cost-per-outcome across every campaign
Paid and community distribution
- A TLDR newsletter placement (first paid spend), a bytes.dev newsletter sponsorship, an EthicalAds campaign (per-segment copy and creative), Reddit Ads, and a paid-channel experiment plan
- Creator and sponsorship lists mined from a network of thousands
- An agent-ecosystem play: registered the product as an agent, plus an agent-injection campaign plan
Team and ops
- Hired and directed our DevRel engineer, Steve McDougall, brought on Flo Merian as our Product Hunt hunter, and onboarded our brand-and-marketing agency, Conversion Factory
Research and evaluation
- A pricing evaluation, competitor ad-intelligence research, and a developer-marketing playbook synthesis
And the dogfooding receipt
- 27 product issues filed to engineering from real use, and the #1 power user of the Tabstack API at 29,938 calls
No shame to my game. Here's my metrics dashboard as of July 7, 2026.
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.
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.
Here’s exactly what I did, week by week, and the play you can take from each one.
Before Day One: I Built on the Product First
The best decision I made happened before my first day.
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.
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.
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.
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.
Rival is open source. You can try the live demo or dig into the code.
Week One: I Stood Up My Systems Before I Ran Any Marketing
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.
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.
The play: don’t start with campaigns. Start with the infrastructure that makes every campaign easier to run.
Week Two: I Turned the Docs Gap Into a System
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.
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.
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.
Week Three: I Did the Strategic Work, Then Placed the Bets
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.
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?
The answer was five bets, each one tied to how developers actually find and adopt tools: showing up in the tools they already use, a public schema library where every use case becomes its own discoverable entry point, content built to be found by the AI models developers now ask, brand and marketing execution, and field and community distribution.
The play: do the strategic work before you spend a dollar. Understand the market, define what you are and how you differ, then make a short list of bets that balance quick wins against longer plays that compound. The best opportunities will make themselves known this way.
Week Four: I Launched by Day 24, With the Data Dashboard First
By day 24, we had our first Product Hunt launch live.
Product Hunt was deliberate, and not for the obvious reason that developers are there. It’s a source the AI models trust, so a launch doubles as training signal for the assistants developers now ask. I also have a track record there, which buys speed. I planned and launched this one in a few days. Early, trusted, and fast to run was exactly the profile I wanted for a first move.
Two days before it went live, I stood up our first metrics dashboard across the whole developer journey, API usage, activation funnel, time to value, playground to production, so the moment traffic hit I could see what it did, not just that it showed up. Instrument before you ship, or the launch is noise you can’t learn from.
The play: early on, ship one real growth effort, and choose it by impact. You’ll have a hundred things you could do. The discipline is picking the one that drives the most growth right now and getting it out, while the longer-term work keeps moving in parallel.
Weeks Five and Six: I Built an Agent to Scale Myself, Not to Replace Myself
There’s too much for one person to track. Competitors, community, prospects, sponsorships, content, events. So I built a go-to-market agent, on the open-source Hermes framework, to take the repetitive gathering off my plate.
The agent runs the recurring jobs on a schedule. Daily competitive-intelligence digests. Community listening across Hacker News, Reddit, GitHub, and more. Prospect signals from our CRM. Prospecting batches. Sponsorship research. A social pipeline with MentionDrop. Event-prep briefs. It commits its reports and pings me.
Here’s a concrete one. Rival already runs a cron every night, pulling competitor updates and pushing them into the GTM Command Center. The agent picks that up and synthesizes it, so instead of reading raw diffs every morning, I get the read that actually matters.
The agent gathers and drafts. I read every report, make the call, and do the work. The system makes me faster. It does not replace me. That distinction is the whole reason it works: I get leverage without giving up a single decision.
The play: use AI to scale yourself. There is always more GTM work than one person can do by hand, so hand the repetitive gathering to an agent and keep your hours for judgment and action. One person can run a full operation this way. The leverage is real, and every decision stays yours.
Week Seven: The Machine Started Pumping
This was the inflection point. The daily reports turned on, and the systems started feeding me fresh intelligence every morning instead of me hunting for it.
Two things made it click. First, I wired the systems together: the agent could now read and write the CRM directly, and the GTM Command Center held the single source of positioning that fed everything else. Second, I built the operating layer that gives all that daily output somewhere to go, a content calendar and backlog, a distribution system, and outreach lists pulled from my own network of thousands of contacts.
The play: this is where the work starts compounding. Once your systems connect and feed you output, the job flips from setting the machine up to running on what it produces, and every new problem is easier to solve because the system to handle it is already there.
Week Eight: I Turned Product Hunt Into an Engine
Our second launch, Web Research, went out about a month after the first. From there they came almost weekly, on purpose. A launch every week is a forcing function, and the amount of work behind a single one is the part people underestimate: the positioning and messaging, the website work itself (product pages designed and built, homepage and navigation updates, the SEO and discoverability layer), a working demo, images and launch cards, a video, the Product Hunt listing and maker comment, forum posts, social, a launch email, and answering every question in the thread on the day. The fixed deadline is what gets all of it out the door, week after week.
I already knew the whole site needed a rebuild. I didn’t wait for it. I designed and built a focused product page for this launch myself, so we had something strong to land on now, and left the full rebuild for later.
The play: don’t wait for perfect resourcing to move. Ship a focused page instead of blocking on a full redo, an agency, or a designer, and own your launch surface end to end. Then put yourself on a cadence and let it do the forcing. Nothing gets work out the door like a deadline you committed to.
Week Nine: I Rebuilt the Whole Website Presence in a Weekend
I knew from early on the site needed a full facelift. The old homepage was a single page, and it was weak. Developers couldn’t tell what Tabstack did or didn’t do.
But I didn’t rebuild the whole site first. I did higher-leverage work and waited. When our research page shipped as a one-off landing page with a new design, it set the standard the rest of the site had to meet. So the facelift happened between launches: the product pages, the homepage relaunch, and the search-visibility layer underneath it, llms.txt, per-page structured data, canonicals, a branded 404, a clean sitemap, so the models developers ask can actually find us. Each launch got a stronger surface to land on, and the presence kept improving without ever blocking a launch.
The play: improve your GTM presence, but sequence it. Recognize the big investment early, then hold off until it’s the highest-leverage move instead of the urgent one. Let one strong page set the design and messaging standard, then roll the rest out between launches, so your presence keeps getting better without ever blocking one.
Week Ten: I Reinvested in the Systems & Data
I pulled the whole operation into one terminal workspace with memory, so I start every session already in context instead of re-explaining myself. And I improved the data. With consent off by default and nothing collected unless you allow it, reliable attribution is genuinely hard, so I made it work within that limit, keeping referrer and UTM data through the consent step instead of losing it. A better workspace makes me faster. Fuller data makes every decision better. I do everything in here from ad copy, to email outreach drafts, to building agent skills. It empowers me to do everything within the defined system.
This is also the week I turned on our first paid spend, a TLDR newsletter placement, and not a day before. I waited until the site and the developer experience were good enough that the traffic would land on something ready.
The play: reinvest in your own systems and your data as you go. Efficiency and better information both compound. And don’t buy traffic until you’ve built something worth sending it to.
Week Eleven: The Systems Started Paying Me Back
By now, running go-to-market like an engineer had a feel to it. Every time I hit a wall, I solved it for good.
I’d made launch images by hand for three launches, hours each in Claude Design, so I built a helper that renders them on brand in minutes. My next launch’s imagery took me minutes. I planned a ten-category schema library and had the agent build it in a single overnight batch while I reviewed and shipped it in the morning, weeks of work done in hours. And I measured it hard: a four-launch traffic comparison, a growth report going back to April, attribution diagnostics, a case-study shortlist of our most-engaged orgs, and an exec narrative packaged into a deck.
I’m not doing less. The more my systems handle, the more I get to take on, well beyond what one person could carry alone.
The play: solve every hurdle once. Feel the pain a couple of times, then build the thing that removes it for good, a tool that turns hours of design work into minutes, an agent that runs an overnight build while you sleep. Each fix makes the next thing easier, and easier is what lets one person do the work of a team. That is what running go-to-market like an engineer actually buys you.
Week Twelve: Not Every Launch Is a Tentpole
Our fifth launch, Schema Source, was a quick one. It put eyes on the schema source tool our team built and the schema library of pre-defined schemas my agent built and kept the cadence alive without a heavy lift.
The rest of the week went to the work that doesn’t announce itself. I integrated a fresh positioning pass so our message stayed sharp as we grew, and I got the Browser Automation launch copy ready for the next week, keeping it strictly to what was actually shipping, because overselling a developer tool costs you the moment someone tries it.
The play: not every launch has to be a tentpole. A quick, light launch off something you already shipped keeps the cadence alive and puts eyes on an asset, without the heavy lift of a marquee release. The cadence is the engine. Sometimes you just feed it with what you already have.
Week Thirteen: Final Push before Day 90
Week thirteen ran hard. The sixth launch, Browser Automation, went out with its announcement email. I shipped a competitor-brief tool, and finished the CRM enrichment layer that turns an email into a cited public profile on Tabstack’s own research endpoint. Even then I kept tuning the systems, because at day 90 I’m still sharpening them.
Then I measured my own 90 days the same way I measure a launch. Here’s what the systems produced:
Tabstack is one tool in my stack, but it earns its spot. Rival is built entirely on it. Here’s a small example of why. I wanted to pull a recipe off a page and get clean, structured JSON back for a blog. I asked Claude to just do it, and it failed. Then I had it call Tabstack, and the data came back in seconds, structured exactly the way I needed and exactly what the model couldn’t produce on its own.
The Bottom Line
I grew signups 71% in 90 days by building the systems that made me faster. Work smarter, not harder.
If you market a developer tool, or you’re a developer thinking about marketing your own, here’s the whole thing in one breath. Learn the product by building on it. Fix the developer experience, and build the system that keeps it fixed. Turn launches into a cadence, and never launch without your data ready. Use AI to scale yourself without handing over the judgment. And solve every hurdle once.
You don’t have to be an engineer to run go-to-market this way. It just helps to think like one. I’m a marketer for developers because I’m a developer, and after 90 days I’m more sure than ever that’s the advantage.
If you’re building agents that need to read the live web, Tabstack is worth a look. Grab an API key.
Everything I Built and Shipped
If you want the action behind the playbook, here’s the full body of work from the quarter.
The systems (the machine everything runs on)
Skills, subagents, and commands I built
Marketing website (built and rebuilt)
Docs
Developer tooling
Product Hunt launches (six)
GTM intelligence and reporting
Content
Positioning and messaging
Specs and plans
Analytics and dashboards
Paid and community distribution
Team and ops
Research and evaluation
And the dogfooding receipt
Campaign Performance
No shame to my game. Here's my metrics dashboard as of July 7, 2026.
Read Next
I Stopped Checking My Mentions Dashboard. Now an Agent Drafts the Replies.
How MentionDrop's MCP turned social listening from a dashboard I ignored into a revenue-driving to-do list my GTM agent builds every morning.
How I Deployed Hermes Agent on Railway with Telegram (And Every Gotcha I Hit Along the Way)
10 undocumented gotchas for deploying Hermes agent on Railway with Telegram—from the wrong gateway command to zombie MCP processes to the volume path that wipes your bot's memory on every deploy.
I launched Built for Devs on Product Hunt today
Developer adoption intelligence for dev tool founders launched today on Product Hunt. Plus a free DevRel Playbook for this community.
Every Developer Abandoned This Product in 3 Minutes
Ten developers. Five different segments. One product. Every developer abandoned it in three minutes.