With its three-column layout, beautiful design, and quick copy-paste examples, there’s a good reason that Stripe is often the first mentioned in developer experience conversations. The payments API company has made a name for itself with great developer documentation and a product that backs up these expectations. Yet, if we go back to the early days—more than ten years ago, eons in developer time—we’ll find the seeds of their success that are even more worthy of your emulation.
Thankfully, the Wayback Machine helps us to steal a glance at Stripe circa 2011:
In this early landing page, Stripe identified the audience, the problem, and the benefits all within around 300 short words. It also guided developers toward further exploration and self-service. That next step from the Stripe homepage was the documentation that made them famous. But developers might not have continued the journey if not for the way Stripe described its service.
More than 10 years later, there are still lessons we can all learn from this previous Stripe homepage.
Clearly Identify Your Audience
Payments are a big topic with a huge impact to the business. It would be natural to expect finance or operations to be the real buyer of Stripe’s services, especially in the early 2010s. Instead, from its earliest days, Stripe planted its flag with developers. At the very top of Stripe’s early homepage is a clear message:
Payments for developers
That headline might not work today, even for Stripe ( “Payments infrastructure for the internet,” says its 2022 homepage). But it’s a good template to start from, if only to test your company’s willingness to focus on a technical audience.
Many companies with developer tools have other audiences. These developer-enabled companies will address other audiences on their primary marketing pages. But if you’re going to emulate Stripe for its documentation, you can’t ignore its early and unflinching focus on developers.
At the bottom of that 2011 homepage, they re-iterated the earlier flag-planting: as developers, they understand what a coder wants from a payments API. While they backed it up with a solid product, this homepage showed developers they were serious and not just with patronizing promises.
Articulate the Problem You Solve
To accept a credit card before Stripe required considerable developer effort and a multi-step process. Among the requirements were a merchant account at a bank, a payment gateway, and an encrypted website (something not as widespread as it is now). Before a developer could write any code, they needed to arrange these pre-requisites, each coming with its own cost. In many organizations, that meant getting non-developers involved.
While there were others who provided payment services, Stripe saw its real competition as this entrenched process that most required. The developer problems they solved were the sharp edges that snagged devs and kept them from code.
Right there, in the first section of its homepage, Stripe made a huge promise:
You don’t need a merchant account or gateway
In fact, that might have made a better sub-heading at the time. Instead, they used a growing term, full-stack, to reference how they solved the developer problem (a front-end widget and backend APIs). Most importantly, Stripe declared its competitor, though not by name. Stripe was going after anyone who pushed all the hard payments stuff to developers.
There were some competitors who absorbed the bureaucracy of gateways and merchant accounts. These solutions involved developer trade-offs, such as giving up customization. In some cases, developers would need to direct traffic to a third party, which took user experience out of the development team’s control.
Before Stripe, there were payment trade-offs, depending on who developers integrated. It was either the red tape overhead of gateways or working within the restrictions of a cookie-cutter vendor. Stripe let developers have the upside of these two solutions without any downsides. The rest of its homepage emphasized these advantages.
Show Your Developer Benefits
Any good marketer knows it’s not about the features, so instead, they make the benefits sing. Often, for developer products, this does not translate to things developers care about. The promises are hand-wavy or make claims that raise more doubts.
Stripe framed its benefits in developer terms and backed each up with a link to prove its point.
Payments require sensitive data, like credit card numbers. Safely collecting, storing, and retrieving this data should be top-of-mind for developers. A service that promises to “handle everything” had better put these details front and center. Stripe does that with the first detailed benefit on the page.
Further, it explains that you can build your own payment forms and avoid most PCI requirements. Here, they’re referencing a hurdle the developer may already have in their mind. PCI is a security standard related to how data is collected and stored. This quick highlight shows that Stripe handles this painful compliance—it’s a little bit of the Developer Content Mind Trick in one sentence of a landing page.
To further scream that it’s for developers, Stripe put code on its homepage. And not just a meaningless snippet, this section is a miniature version of its best API docs. It defaults to a curl command that devs can copy-paste directly to their command line, complete with a working API key.
This early homepage also included five other API call examples and the code to support them in Python, Ruby, and PHP (in addition to the curl version). Many modern dev tools don’t provide this level of language support and interactivity in their docs—Stripe had it on its marketing site.
Finally, Stripe was transparent from the start about how it gets paid. In a finance industry known for its fees and involved sales processes, Stripe differentiated itself from the start. Even better than the friendly pay-as-you-go pricing, developers can get started immediately. At the time, it was a breath of fresh air. Today, self-service is a requirement for any developer product.
Apply the Right Lessons from Stripe
Clear, accurate—even beautiful—docs will endear you to the developers who find your product. Stripe was able to attract them in the first place with content that shows they understand developers. You can do the same on your homepage, in your documentation, and every way you engage developers.
EveryDeveloper’s Developer Experience Assessments take a holistic view of your dev-focused product. When you work with us, you can apply lessons from Stripe to reach more developers.
Our expert team can help you:
- Identify the right developers
- Articulate their technical problems
- Uncover opportunities for improvement
Work with EveryDeveloper and follow our proven method used by the best dev-focused companies to attract, engage, and retain developers.