Developer Experience Is Customer Experience

An investor asked me what our customer experience strategy was. I said "our API documentation." They laughed. Then I showed them the numbers, and they stopped laughing.

For a platform company, the developer is the customer. Not a secondary user. Not a technical implementer. The customer. The person who evaluates your product, decides to adopt it, integrates it, and either stays or leaves based on the quality of their experience. Everything we do in DX -- documentation, SDKs, error messages, dashboards, tooling -- is customer experience work.

This is not a metaphor or a philosophical position. It is a structural reality that changes how you allocate resources, measure success, and make product decisions.

The platform paradox

Platform companies face a paradox: our direct customer (the developer) is not our end user (the traveler). The developer builds a product. The traveler uses that product. We never interact with the traveler directly.

This creates a chain of experience. If our API is hard to integrate, the developer builds a worse product. The traveler has a worse experience. Fewer travelers use the product. The developer gets less value from the integration. They churn.

The reverse is also true. If our API is easy to integrate, the developer builds a better product faster. The traveler has a better experience. Usage grows. The developer stays and expands. Revenue grows.

Developer satisfaction is a leading indicator of platform health. When developers are happy, end-user products get better, usage grows, and the business thrives. When developers are frustrated, the entire chain degrades.

This is why we track developer satisfaction with the same rigor that consumer companies track customer satisfaction. Not as a vanity metric. As a business metric that predicts revenue.

NPS for APIs

We measure Net Promoter Score specifically for our API product. The question is simple: "How likely are you to recommend Nowah's API to a colleague?" Scored 0-10, with the standard NPS calculation (promoters minus detractors).

But we go beyond the single NPS question. Our quarterly survey includes questions specific to different DX dimensions: API design quality, documentation clarity, SDK usefulness, error message helpfulness, dashboard usability, and support responsiveness.

This dimensional breakdown tells us where to invest. A high overall NPS with low documentation scores means documentation is dragging down an otherwise strong product. A low NPS with high API design scores and low tooling scores means tooling needs attention.

The survey goes to every developer who has made at least 10 API calls in the past quarter. We exclude one-time evaluators because their experience is too preliminary to be representative.

We publish the NPS trend (though not the absolute number) on our public status page. Transparency about developer satisfaction keeps us accountable and gives prospective developers confidence that we take their experience seriously.

The developer-as-customer framework

Customer success principles apply directly to developer relations when you think of developers as customers.

Onboarding. Consumer products obsess over first-time user experience. We obsess over time-to-first-API-call. A developer who has a smooth first experience is far more likely to stay long-term. We measure this with the same precision that consumer apps measure their activation funnels.

Health scoring. Consumer SaaS companies track customer health scores based on login frequency, feature adoption, and support interactions. We track developer health scores based on API call frequency, endpoint diversity, error rates, and support ticket history. A developer whose error rate is climbing and API calls are declining is at risk of churning.

Expansion. Consumer companies track upsell and cross-sell. We track developers moving from the free tier to paid, from search-only to booking, from single-market to multi-market. The expansion path is different, but the principle is the same: a happy customer grows.

Retention. Developer-first companies that invest in DX see dramatically higher retention rates. Developers who have a smooth onboarding experience retain at much higher rates than those who struggled. The first week determines the next year.

Making DX a first-class product function

In too many companies, developer experience is a side project. It lives inside the engineering team. It does not have its own product manager. It does not have a roadmap. It gets attention when someone complains and gets forgotten when they stop.

We made DX a first-class product function. It reports to product leadership, not engineering leadership. It has its own PM, its own designer, and its own roadmap. DX features compete for priority with consumer features on the same basis: impact on business metrics.

This structural decision matters more than any individual DX improvement. When DX has a seat at the product table, it gets resources. When it does not, it gets whatever time engineers can spare after shipping consumer features.

The industry average for documentation satisfaction is about 3.2 out of 5. We target above 4.5. That gap is not achieved by being slightly more careful. It is achieved by treating documentation as a product with its own quality bar, its own testing infrastructure, and its own team responsible for hitting the number.

Developer-first travel companies grow faster because their go-to-market is product-led. Developers discover the product, evaluate it through self-serve tools, adopt it based on their experience, and expand their usage over time. The developer experience is the entire go-to-market funnel.

If your developers are your customers, your developer experience is your customer experience. And if your customer experience is a side project, your customers will find a company where it is not.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.