This confusion has been with the industry since the beginning. Providers treat developers as the customer, but developers are frequently not the ones cutting the cheque. The customer is the business that employs the developer, the end user of the application they build, or the procurement office that has to approve the contract.
Both matter, and they need different things. The developer needs frictionless evaluation, good documentation, fast onboarding and a client that works. The buyer needs predictable pricing, a security review they can pass, an SLA, a support commitment, and confidence that you will still exist in three years. An API program that serves only the developer never gets purchased; one that serves only the buyer never gets adopted, because the developer will quietly choose something else during evaluation.
So design for both explicitly. Self-service everything the developer needs to prove it works, and put everything the buyer needs — pricing, terms, SLA, security posture, compliance — on a public page they can forward to legal without asking you.
A sharp diagnostic: look at whose feedback actually changes your road map. That tells you who your organization truly considers the customer, whatever the strategy deck says — and if the answer is neither the developer nor the buyer but an internal stakeholder, that explains a great deal.
