How to go to market with a developer tool

By Shane O'Connor · Updated 23 October 2026

Take a developer tool to market in five steps, in this order, after at least 10 conversations with people who have the problem. With answers from Shane O'Connor, creator of the GTM Co-Founder skills and GTM Partner at QC Growth (interview, 23 October 2026).

The five steps:

Write who it is for as a person with a job, for example "platform engineers at 50 to 500 person companies running Kubernetes" instead of "developers".
Get your first 10 to 50 users from the places those people already discuss the problem and from one-to-one outreach. A launch almost never supplies them.
Choose bottom-up self-serve or an early sales motion with two tests: can one developer get value alone in under an hour, and who signs the cheque.
If the tool's value grows with usage, meter on that usage unit instead of seats.
Launch on Hacker News or Product Hunt last, because a launch produces a spike of signups and does not build a base of users.

If you were planning to post a Show HN this week, hold it until you have finished steps 1 to 4. The Kubernetes example, the outreach message, the under-an-hour test and the point that a launch gives a spike, not a base, come from Shane's work advising developer tool and AI companies on go-to-market.

What do you need before you start going to market with a developer tool?

You need two things before step 1, plus three optional items if you want a coding agent to run the strategy work with you:

Conversations with at least 10 people who have the problem. If you have not had them yet, have them before you do anything else on this page.
A product one developer can install or try. Step 3 asks you to time how long first value takes, and you cannot time a demo.
Optional: a coding agent that supports skills or plugins. Use Claude Code, Cursor or another agent that supports skills or plugins. The about page has the full list.
Optional: Node.js, for the npx install. The homepage lists Node.js as required for npx skills add. No minimum version is published, so use a current LTS release.
Optional: read and write access to your product repo for the agent. The start-here skill scans the repo and writes docs/gtm-cofounder/founder-brief.md.

Step 1: Who exactly is your developer tool for?

The first go-to-market decision to commit to is who the tool is for, written as a person with a job rather than a market. "Developers" names nobody you can contact. "Platform engineers at 50 to 500 person companies running Kubernetes" names people you can find, read and write to by name.

Fill in this sentence for your tool:

<role> at <company size> companies running <stack or environment>,
who need to <job> and currently use <workaround>.

The Kubernetes example covers the first half of the template. The last two slots carry most of the weight. The job tells you what to put in the message. The workaround tells you what you are replacing, which is often a script, a spreadsheet or nothing at all.

Founders who skip this step go straight to launch and content, and get a spike of signups that never comes back, because the message was written for everyone.

Expected result: one sentence that a teammate could use to name 10 real people on LinkedIn or GitHub without asking you a follow-up question. If they need to ask "which kind of engineer?", the sentence is not done.

Step 2: Where do a developer tool's first 10 to 50 users come from?

Across the dev tool teams Shane has worked with, the first 10 to 50 users almost never came from the launch. They came from the places your target users already discuss the problem, and from direct one-to-one outreach.

List where the Step 1 person already talks about the problem: the repos they star, the issue trackers they comment in, the forums and chat groups where they ask for help with the job you named.
Find specific people in those places who show a real signal. For example, they starred your repo, opened an issue on a tool you replace, or asked a question your product answers.
Message each person individually. Base each opener on what that person did.

For one data-tooling client, the outreach that worked followed this pattern:

Saw you starred <repo-name>. What are you moving data from and to?

The message works for two reasons. The opener refers to something the person did, so it reads as written to them. The question can be answered in one line, and the answer is the information you need. Leave out the pitch and the demo link, so replying costs the person one line. If you do not build a data tool, keep the structure and change the question: name their real action, then ask one plain question about their setup.

Expected result: replies that describe the person's real use case in their own words. Feed that wording back into your Step 1 sentence. If replies keep naming a different role or stack, your ICP sentence is wrong. Rewrite it before you go further.

Step 3: Should a developer tool be self-serve or sales-led?

Two signals decide whether a developer tool should be bottom-up self-serve or needs a sales motion early: whether one developer can get value alone in under an hour, and who signs the cheque.

Signal	Points to bottom-up self-serve	Points to an early sales motion
Time to first value	One engineer installs it and sees results the same day	Value is blocked until someone other than the engineer acts
Prerequisites	None beyond the install	A security review, a data integration or a budget owner before anything works
Buyer	The user, with usage pulling in the buyer later	A separate budget owner who has to approve before use

If your tool lands in the left column, go bottom-up and let usage pull in the buyer. If it lands in the right column, you need a sales motion early. That motion can be the founder doing the selling. You do not need to hire an account executive to start one.

Run this test honestly. In Shane's words: "Most dev tools think they're the first kind and are the second." Time a fresh install with someone outside your team. Sit with them, start a timer and do not help. Your own team has credentials, context and a configured environment, so their install time tells you nothing.

The daily.dev developer GTM guide (April 2026) sets a different bar: "Developers should reach their first 'aha moment' in under 15 minutes." That figure measures onboarding speed for a product-led tool. The under-an-hour test asks an earlier question: can the engineer reach value alone at all, without waiting on a reviewer, an integration or a budget? For the buyer signal, Markepear puts the position directly: "you market to developers and you sell to their boss."

Expected result: a decision recorded in one line, such as "bottom-up, outsider reached value alone in the session" or "founder-led sales, blocked on security review."

Step 4: What should a developer tool charge for?

The most common launch pricing mistake is charging per seat when the tool's value comes from usage. A per-seat price taxes the behaviour you want more of. A close second is a free tier so generous that no real company ever needs to upgrade.

Write down three lines before you set any price:

Value unit:     <the thing that grows when a customer gets more value>
Price meter:    <the thing your invoice counts>
Upgrade point:  <the specific moment a real company hits the free limit>

The first two lines should name the same unit. If your value unit is rows synced, builds run or requests served, and your meter is seats, you have the first mistake.

The third line tests the free tier. Describe the moment a real company, of the size in your Step 1 sentence, reaches the limit in normal work. If you cannot name that moment, the tier is too generous and free users have no reason to pay.

Set the meter first and the number second: a price on the wrong unit stays wrong whatever the number is.

Step 5: When should you launch a developer tool on Hacker News or Product Hunt?

Launch a developer tool on Hacker News or Product Hunt after Step 2 has given you a base of users and Steps 3 and 4 are decided. A launch post produces a spike of attention and does not create that base. Founders expect a Product Hunt or Hacker News post to bring their first users. Those posts give a spike, not a base, and first users almost never come from the launch.

Other guides put the launch earlier. The business.daily.dev launch guide (April 2026) describes platforms like GitHub and Hacker News as "critical for early traction." The ordering argument here is narrower. Traction from a launch only lasts if the people who arrive find a message written for them and a product they can get value from on their own. Steps 1 to 3 are how you know that is true before the traffic arrives.

Before you post, run this pre-launch gate:

[ ] Step 1: a teammate named 10 real people from your ICP sentence
[ ] Step 2: <number> users from one-to-one outreach still active after <period>
[ ] Step 3: motion decision recorded in one line
[ ] Step 4: price meter and upgrade point written down

Expected result: every line checked before you post.

How do you run these steps with the GTM Co-Founder agent skills?

The GTM Co-Founder is a free, MIT-licensed set of 20 Agent Skills that runs these strategy steps inside Claude Code, Cursor or another coding agent that supports skills or plugins. The source is on GitHub, and the plain-text overview lists all 20 skills. See the GTM Co-Founder open-source skills for developer tools for an overview.

Install the skills. With any agent that supports skills:
```
npx skills add AIDevGTM/gtm-cofounder
```
Or, in Claude Code, add the plugin marketplace and install the plugin:
```
/plugin marketplace add AIDevGTM/gtm-cofounder
/plugin install gtm-cofounder@gtm-cofounder
```
Expected result: the skills are installed and start-here is available in your agent.
Open your product repo in the agent and run the start-here skill:
```
/start-here
```
Expected result: it scans the repo, asks you five questions and writes docs/gtm-cofounder/founder-brief.md. Answer them with your Step 1 sentence and your conversation notes.
Run the research-the-market skill. Expected result: market research with linked sources that you can open and check.
Run the strategy-and-roadmap skill. Expected result: a prioritized GTM roadmap written to docs/gtm-cofounder/gtm-roadmap.md.
Run the review-the-work skill. Expected result: an adversarial review pass on the plan before you act on it.

The skills cover the strategy half of go-to-market: who the product is for, why they pay, first users, positioning, launch and pricing. They do not cover SEO tactics, ad operations or copy polishing.

How do you verify the plan is working?

A developer tool go-to-market plan is working when users from one-to-one outreach are still active after any launch spike fades and revenue moves with usage. Run these five checks against the steps above:

Check	How to run it	Expected result
ICP sentence	Give a teammate your Step 1 sentence and ask them to name 10 real people who match it	They name 10 without asking which role or stack you mean
Outreach replies	Read each reply to your one-to-one messages	Replies describe a concrete use case, not general interest
Time to first value	Watch someone outside the team do a fresh install without help	An outsider reaches value alone inside the hour. If a security review, data integration or budget owner blocks them, plan a founder-led sales motion.
Retention after any launch	Compare users still active after the launch with the launch-day spike	A group of returning users remains after the spike fades
Pricing meter	Check whether revenue moves when customer usage grows	Revenue grows with usage

If you use the agent path, the review-the-work skill gives an adversarial review of the plan before you act on it. Run it again after you change the Step 1 sentence or the pricing meter.

What if it does not work? Troubleshooting by symptom

Each row below starts from a symptom you can see in a stalled developer tool go-to-market, then gives the likely cause and the fix, with the step to redo where one applies.

Symptom	Likely cause	Fix
A launch brought signups that never came back	The message was written for everyone	Rewrite the Step 1 sentence as a person with a job, then rewrite the message for that person
Upvotes but no users	The launch was used for acquisition	Go back to communities and one-to-one outreach (Step 2)
Trials stall at security review or procurement	A product that needs a sales motion is being run as self-serve	Start founder-led selling to the budget owner (Step 3)
Usage grows and revenue does not	Per-seat price on a tool whose value comes from usage	Meter on the usage unit (Step 4)
Free users never upgrade	The free tier is too generous	Move the limit to a point real companies reach in normal work (Step 4)
Outreach gets no replies	Generic pitch	Open on a real signal and ask one plain question (Step 2)
Your coding agent does not recognize the GTM Co-Founder skills	The agent does not support the Agent Skills specification	Switch to Claude Code, Cursor or another agent that supports skills or plugins (the about page has the full list) and run `npx skills add AIDevGTM/gtm-cofounder`, or in Claude Code use the plugin commands

When should you not use a GTM playbook or the GTM Co-Founder skills?

Skip the GTM Co-Founder skills if you have not yet spoken to 10 people with the problem. Talk to them first. The skills will tell you the same thing, and no roadmap can replace what those conversations reveal about the job and the workaround.

If you already have a GTM lead running a working motion, you do not need a roadmap from scratch. Use their motion and fix the specific step that is failing.

The skills also stay out of execution work. They do not handle SEO tactics, ad operations or copy polishing, so use specialist tools or people for those. The skills are built for whoever owns early go-to-market for a developer tool or AI product and has no playbook: a technical founder, a first GTM hire or a fractional operator.

The project is built by Shane O'Connor, creator of the GTM Co-Founder skills, a GTM advisor based in Cork, Ireland. The sources and contributors behind the GTM Co-Founder playbook are named on the credits page.

What should you do next?

Read the plain-text overview of all 20 GTM Co-Founder skills to see which ones match the step you are on.
Follow the GTM Co-Founder skills quickstart to install the skills and run start-here.
For hands-on help, Shane O'Connor works with founders as GTM Partner at QC Growth.

Frequently asked questions

Should I launch my developer tool on Hacker News or Product Hunt first?

No. Launch after you have a base of users from one-to-one outreach and a message that has been tested in conversation. A launch gives a spike of attention and almost never supplies first users. A launch is still useful for visibility once the base exists.

How do I know if my developer tool needs a sales motion?

Apply two tests: can one developer get value alone in under an hour, and who signs the cheque. If the product needs a security review, a data integration or a budget owner before anything works, you need a sales motion early, and the founder can run it. Time a fresh install with someone outside your team, because your own team's install time is misleading.

How many customer conversations should I have before writing a GTM plan?

Have at least 10 conversations with people who have the problem before you write a plan. Do this before running the skills, because the skills will reach the same conclusion. Use the conversations to fill in the job and workaround slots of your ICP sentence.

Should a developer tool charge per seat or per usage?

If the tool's value comes from usage, meter on the usage unit. A per-seat price taxes the behaviour you want more of. Also check the free tier: you should be able to name the point where a real company hits the limit.

Is the GTM Co-Founder open source, and which coding agents does it run in?

Yes. The GTM Co-Founder is free and open source under the MIT license, with the code on GitHub. It is a set of 20 Agent Skills that runs inside Claude Code, Cursor and other agents that support skills or plugins.

Does the GTM Co-Founder skills pack cover SEO or paid ads?

No. The skills cover the strategy half of go-to-market: who the product is for, why they pay, first users, positioning, launch and pricing. SEO tactics, ad operations and copy polishing are out of scope, so use specialist tools or people for those.