Use Free Tools to Market Your Developer Product

• 

  Adam DuVanderPrincipal Consultant
  EveryDeveloper

Adam DuVander is a developer, marketer, and founder of EveryDeveloper, where he helps great dev tool companies reach more of the right developers with content. In this post, Adam shares an excerpt from his book, Developer Marketing Does Not Exist, on how some of the best developer companies have used tools as marketing—with ideas for how you can do the same.

A pharmacy may be the last place you'd think would attract children. But my young cousins and I often ended up at that corner of the shopping center neighboring our grandmother's house. The reason? The pharmacy had the most advanced technology in town.

One by one, we would take turns sitting at the wooden desk. After placing a tiny arm through a permanently attached cuff, we’d press the green button on the tabletop to commence the arm tightening. Moments later, it would display the blood pressure it recorded on the screen. Systolic and diastolic readings didn’t mean much to us as kids, but we weren’t the intended audience.

With adults, that machine did its job beautifully. It wasn’t coin-operated; this was a free resource for the community. It’s not like someone using this machine could immediately buy hypertension medication—they’d need to see a doctor for a prescription.

It was meant to get shoppers to associate the store with their health. After that, perhaps, their medications. That machine, which entertained me as a child, was a physical example of using tools as marketing.

To attract developers to your company, tools can be even more effective.

Three Developer Startups That Hurled

When your entire company is an API, it’s important to easily test API requests. That’s how Twilio made its first acquisition, a little developer project called Hurl. The simple website, built at a hackathon in 48 hours, can make API requests and inspect them right in your browser. Years later, it’s part of at least three developer startup stories:

• Twilio
• Runscope
• Insomnia

While each used the Hurl differently, they started with the knowledge that developers want an easy way to test out requests and responses with an API.

The team at Twilio was already the biggest user and referrer to Hurl before they acquired it.  When developers would write into Twilio support, the reply would often require an example API call. Twilio support wanted a friendly tool that wouldn’t take their customer additional time to install or set up. Hurl could help them provide a useful reply that was quick to understand.

After evangelizing Hurl to hundreds of developers, the site had a following of its own, even outside Twilio usage. Since the original creators had moved on to other projects, Twilio purchased Hurl so the company could maintain this important support tool. In time, it also became a marketing tool, as developers learned of Twilio through Hurl.

However, it wasn’t core to Twilio’s communication API products. Keeping the code maintained and the servers running became a burden, one a former Twilio evangelist was happy to take on.

A new company, Runscope, took over Hurl and used it to acquire more targeted customers. The company’s API inspection tools were a great match for Hurl. Chances are, if you had a one-off API call to review, you might have ongoing needs around APIs. The hunch paid off, as Hurl and other developer tools became referrers, either directly or via retargeted marketing, for Runscope’s trial and paid product.

Eventually, the company moved toward more enterprise accounts and Hurl was less useful for potential leads.

A third company, Insomnia, used the site to acquire customers of its API request client. Rather than siphon off leads, Insomnia redirected visitors to its installable software available only for Mac.

The community tool aspect of Hurl went away and with it a lot of the usefulness for developer marketing. However, Insomnia became the third startup to gain traction off a single, simple developer project built in two days.

The three startups went on to various levels of success:

• Insomnia was acquired by API platform Kong
• Twilio is now a publicly-traded company and darling of Wall Street investors
• Runscope hit profitability before selling to software conglomerate CA Technologies, now a part of Broadcom

When Developer Marketing Does Not Exist was published, Hurl's domain had ended up in the hands of squatters. It looked like the story of Hurl had come to a close. As of this publication, it seems like it’s been picked up by another developer tool, Pipedream.

Though you can’t have Hurl for your developer company,

the developer tool-as-marketing approach remains a popular way to gain mindshare, links, and traffic with developer audiences.

The Runscope Playbook

With Hurl’s success, Runscope looked to expand its reach with more developer tools. It acquired and sponsored several others, testing the waters to see what would drive traffic and signups to their product.

Each required a little up-front effort, either to build or negotiate, then the team could keep an eye on its results. When something didn’t work, they’d close it down to focus resources on the tools which delivered the best. At its height, there were nearly a dozen developer tools on its community projects page.

Some of the tools Runscope developed, acquired, or sponsored:

• Requestbin
• Authentication testing
• Embeddable cURL commands
• JSON object generator
• API changelog service
• HTTP status code reference
• Mock API server

Each tool linked to Runscope and also embedded a tracking pixel for retargeted ads. The results were that Runscope was able to acquire the right developers for less than other methods. The company also used content, events, and other developer marketing techniques. But developer tools were the channel that performed the best.

In a 2014 talk at Heavybit, Runscope founder John Sheehan identified three rules for using the Runscope playbook:

1. Don’t require a sign up
2. Do one thing well
3. Make it free

These rules reflect the philosophy used throughout Developer Marketing Does Not Exist:

education over promotion. This motto, a useful gauge for your marketing tool, can also be applied to events, community, and even advertising.

Each simply needs to employ the Developer Content Mind Trick, a concept brilliantly used by Gremlin, LaunchDarkly, and other developer companies.

Your goal with your developer tool is to gain word of mouth and links. Developers are more likely to share a tool that doesn’t have a catch—such as a required signup or a paid plan. Just like a gated guide, a simple tool that requires an email address will increase skepticism.

The middle rule—to do one thing well—is also important: it’s easier to recommend something that solves a specific problem rather than a multipurpose tool.

For the same reasons these rules make a tool shareable, developers are also more likely to link to tools that check all three boxes. And links are an important part of what will make these tools rank in search engines. Without a lot of content, they need links to supply both the authority and the context (through the link text).

Find Your Targeted Developer Tool

Now you are ready to follow in the footsteps of Runscope and others with a simple developer tool you can use as marketing. As with content, you’ll want this tool to provide developers with the solution to a common problem. Unlike content, which might discuss the topic or hold your hand through a manual solution (read more about Editorial Strategy for Technical SaaS), your tool will provide—or at least streamline—the end result.

Before you or your team dive into code, it’s important to consider other options. There are at least three ways to execute the tool-as-marketing strategy:

• Build it
• Buy it
• Sponsor it

All three of these were present in the Runscope playbook. While they certainly built their own, the most successful projects already existed.

A developer’s approach is typically to start something new, but often it’s best to look for someone who has already done it better. That’s a message every developer company shares in their “build vs. buy” communications, yet it’s easy to forget when it comes to your own projects.

As you brainstorm ideas for your developer tool, search to see what else already exists. Often, you’ll find projects left behind by independent developers. You may even be able to acquire it with the promise to maintain it.

Keeping a project going is tough, especially when it was started to scratch an itch or simply for fun. Even if there’s only a little traction in a tool, it’ll give you a boost you’d otherwise have to bootstrap.

You may find the owner of an existing tool knows that it’s worth something. In that case, be prepared to make an offer. As you weigh what it’s worth, keep in mind what it would take to rebuild—the tool itself and the traction it’s already gained. It’s easy to forget the value of your team’s time and attention on other projects when determining the price for something that’s already built.

Finally, if the price is higher than you’re comfortable paying to acquire, you can consider sponsorship. There’s not much different about this patron route, as long as you can negotiate the same things you’d include if you owned the property.

For example, you want a link to your site and a little message that helps tie the tool to your product. You may also want a tracking pixel for retargeting. It’s unlikely you’ll want much more, given that part of what helps these tools succeed is their perceived independence.

Two More Rules for Your Tools

On that note, here are two additional rules to get the most out of your developer tool:

1. Give it its own home
2. Keep it relevant to your product

It can be tempting to include your new tool (either built or bought) on your existing site. You may be able to get away with it if there are many existing links. However, it will be much harder to get links and shares under the umbrella of your own site.

The marketing alignment will be too obvious, and developers feel like their friends could be tricked into your funnel. Plus, the singular focus of a tool is diminished when surrounded by your navigation to the rest of your site.

The second of these new rules may be obvious, but I think it’s worth stating explicitly.

The problem your tool solves should be as close to one that your product tackles.

Your product provides a full-featured solution that takes into account edge cases and company needs. The free tool version is much simpler, but likely is enough for 80% of the developers who find it.

API Transformer is a great example of a tool that solves a focused, important problem. With many different API description formats and versions, developers sometimes need to convert between them before they can use the right tools.

APIMatic, the company behind the tool, helps developers turn API descriptions into powerful client libraries, developer portals, and documentation. It shared one small piece of functionality, its ability to convert between formats. Many developers will use the converted document with their own tooling, but a percentage likely stick around to see what’s possible with APIMatic.

Another API tool, Postman, started out as a simple Chrome extension. The company is now valued at $5.6 billion based on its 2021 Series D funding. While no longer attached to Chrome, Postman has kept the same free functionality, which allows developers to try out API requests. Its product is robust, breaking the “do one thing well” rule.

However, the company has added monitors, mock servers, and other features over time. The core initial experience of testing API requests remains. It’s likely that almost every Postman user can casually use the free version. But the company can make a big business off the small percentage that need to upgrade features.

You could get the same marketing benefits from your developer tool. Make it free, easy to use, and relevant to your product. Then simply let visitors know that a next step exists if they need it.

If you’re interested in learning more, be sure to check out the rest of Developer Marketing Does Not Exist. Adam provides practical advice, from creating tutorials and guides to advertising, and will help you uncover what actually resonates with your technical audience so you can start to reach more developers.