How to make your API a catalyst for growth
Justin Michael
Developer Relations Engineer
If you have an API, or plan to have one in the future, it’s important to take full advantage of everything it can do for you and your business. Your API can unlock customers and deals you wouldn’t otherwise have access to and increase awareness of your organization.
This post explains how and why your API can help you grow, and helps you find the lowest cost way to realize the highest growth potential based on your unique circumstances.
If you’re doing the bare minimum with your API because you consider it a necessary evil or a drain on resources, you’re missing out. With some careful consideration, you can transform your API into a low-cost, high-return investment that pays dividends for years to come.
Making developers happy leads to growth
It may seem counterintuitive, but making developers happy can lead to significant growth. Even if developers aren’t your target audience, or are a small fraction of your potential user base, they hold the keys to unlocking three otherwise inaccessible avenues of growth.
First, developers are often involved in key decision making processes. If you need to meet any kind of minimum technical requirements, developers are usually the ones determining those requirements. If you don’t have what developers are looking for, you’ll be removed from consideration early in the discovery process before you’re even aware of the deals you’re missing out on. This applies to your largest potential customers, partners, individual developers, and everyone in between.
Second, developers build things that appeal to wider audiences than you can cater to on your own. If developers aren’t happy with the development experience you offer, they won’t build things with your API, and the users they would have served will remain out of reach.
Third, developers are vocal and influential. They write blog posts, post on social media, discuss things on forums, and chat with their peers. They can work for you, or they can work against you. If developers like what you have to offer, they’ll become your champions and recommend you to their peers. Of course, the inverse is also true, perhaps even more so: if developers don’t like what you have to offer, they’ll be vocal about what they don’t like. Even worse: unhappy developers recommend better alternatives, and those alternatives are probably your competitors.
How to make developers happy
Most developers are not heavily influenced by traditional sales and marketing tactics. Their primary touchpoints for your organization and your product are typically not your marketing pages, your sales team, or your social media accounts. In fact, many developers will actively avoid those things and look for what really matters to them: a good development experience.
Few developers will look at an API by itself, no matter how well-designed, and consider it a good experience. You might be able to get away with providing only an API if what you have to offer is uncommonly small and simple, but if your API has any amount of depth or breadth, most developers will want more.
Specifically, most developers look for and appreciate three key components:
An API that’s well-designed, logical, and intuitive
An idiomatic and robust software development kit (SDK) for their programming language of choice which looks and feels like it was written by an expert in that language
Clear, comprehensive, and easy-to-use documentation for the API and SDK
In addition, many developers want a fourth component:
A robust Model Context Protocol (MCP) server, a new and emerging tool that integrates your systems, and data with AI and large language models (LLMs)
Those four things—your API, SDKs, docs, and MCP server—are the lens developers see you and your product through. They’re an extension of your brand. If you miss the mark on one or more of them, a lot of developers won’t even bother getting started, and the ones who do will quickly get frustrated and abandon you for greener pastures.
However, if you can provide a well-designed API, idiomatic SDKs, clear documentation, and a capable MCP server, developers will be delighted. Well-crafted documentation orients developers quickly, and a great SDK and MCP server lets them hit the ground running and see results quickly. As they dive deeper, the overall quality and ease-of-use of the tools and resources you provide will sustain their motivation and make them eager to build things on your platform. The higher the quality, the more developers will be able to self-serve, which helps them feel accomplished and reduces your support burden.
In short, the combination of a solid API with great SDKs, docs, and an MCP server streamlines development and encourages more people to create amazing things for your users.
How to provide the best developer experience
Producing a well-designed API, great SDKs, comprehensive docs, and an MCP server is easier said than done. Most companies lack the resources to do just one of those things well, let alone all four.
Thankfully, you don’t have to do everything yourself! There are five potential paths to success when it comes to your API, SDKs, and docs:
Depend on your developer community
Hire contractors
Build everything yourself
Use free generators
Work with an API company
There’s no one-size-fits-all solution. We don’t know your specific requirements or situation, so we can’t give you meaningful pros and cons or call out one option as “the best.” Instead, this post provides objective context and insights for each choice.
Specifically, we’re going to look at the following aspects of each option:
Requirements: what you need to bring to the table to make this option happen
Risks and challenges: what can go wrong, and potential difficulties to be aware of
Growth potential: how much a particular option can impact your growth
Who this option is best for: our take on who can benefit the most from each option
You can apply that information to your unique set of circumstances to determine the best path forward for you and your organization.
Full disclosure: we’re an API company, so while there’s bound to be some amount of bias here, our goal is to be as objective as possible. We work hard to be the best solution for a lot of people, but we recognize we’re not going to be the best choice for everyone reading this post. Our primary goal is to help you pick the right option for your needs so you can produce the best API, SDKs, docs, and MCP server possible, even if that means you don’t end up working with us.
Choose wisely
One important note before we continue: the choice you make is going to be a long-term commitment, especially when it comes to your SDKs. Down the road, if you want to switch from one of these options to another, you’ll need to figure out how to transfer a lot of knowledge and context from one entity to another, and that’s not going to be easy.
For example, if you need to switch from one set of SDKs to another, you’ll need to create and implement a costly, painful, and disruptive migration plan for your users. Another possible scenario: you may find that you need to extract critical information and context from one vendor or contractor so you can give it to another, or use that knowledge internally.
Regardless of the specific situation, it’s best to avoid this whole class of problem. We strongly recommend you invest the time and resources required to select the right option up front. That way you can happily and confidently stick with your choice over the long term and save a lot of time, money, and headaches.
With that out of the way, let’s have a look at the options in detail!
Option one: depend on your developer community
If you have a large or engaged enough developer community, you may be able to help and encourage them to build their own SDKs, write language-specific docs, and create MCP servers for your API. A lot of companies take this route in their early days, sometimes out of necessity. This option can work out well, but there are several pitfalls to be aware of.
Requirements
This option has three basic requirements:
A large and/or engaged developer community
A well-designed API
Good documentation for the API itself
It’s important to be realistic about the size and capability of your developer community and what you can expect from them. If you’re well-known and have a really exciting product or service, you may have a large and engaged developer community “built-in.” If you’re new or not well-known, you might be counting on a community forming. Either way, make sure you avoid unrealistic expectations, keep your optimistic projections in check, and pay careful attention to the risks and challenges in the next section.
It’s usually not practical to have an external, amorphous community of developers design or build your API, no matter how large or engaged they are. You may get useful feedback from your community, but at the end of the day you’ll be on the hook for your API’s design and functionality. API design is nuanced and difficult to get right, but if you have access to suitable resources and talent, this approach might be a viable option.
To set your community up for success, they’ll need a solid foundation to build on. A well-designed API is half of that foundation, and the other half is good documentation for your API. You’ll need to commit specialized resources to create and maintain the reference material your community needs to build SDKs, write their own language-specific docs, and create MCP servers.
While technically optional, you should strive to provide top-tier support to your developer community. The more help you can provide, the more they’ll build, and the quality will be higher. The resources required to support your developer community will vary depending on your size, the size of your community, the number of community projects, and the nature of your product or service.
Risks and challenges
This option leaves a lot to chance, so the risks and challenges are numerous:
You won't have any SDKs, language-specific docs, or MCP servers until your community creates them, so your users will need to do the hard work of interfacing with your API manually; that’s not a good experience for them, and it hinders growth at what is probably a vital time for your organization
Your developer community may not be large or engaged enough to create or sustain SDK, docs, and MCP projects over time
If you don’t currently have a large or engaged developer community and plan on one materializing in the future, you’ll need a contingency plan if that doesn’t happen
You and your brand may suffer reputational harm if your community creates poor-quality SDKs, docs, and MCP servers
Your developer community may not create resources or provide support for developers or technologies that are strategically critical (e.g., you may want an SDK for a particular language or an MCP server, but your community hasn’t created them)
Community-driven projects operate on their own timeline and with their own priorities, so your roadmap and strategy may be hamstrung by slow adoption of new features or API versions
Different community projects may not be coordinated with one another, leading to developer confusion, frustration, and slow adoption (e.g., multiple SDKs for the same language, different design and naming patterns across projects, etc.)
You won’t be in control of the overall developer experience, which can lead to several undesirable outcomes:
Community projects and the developers who use them may reason and talk about your API in a way you find undesirable (e.g., they may write code or recommend an approach that puts undue strain on your infrastructure)
Different SDKs may take significantly different approaches to design, functionality, naming, and so on, which creates fragmentation your users will need to untangle
In the future, you may find yourself in a position where you need to spend significant resources course-correcting or supporting community-driven efforts; for example:
You may need to take over, purchase, or make significant contributions to a popular or important community project that’s been abandoned or neglected
The quality and efficacy of community-provided support is often hit-or-miss, so you may need to provide technical support for popular or important SDKs, docs, and MCP servers you have little or no control over
Earlier we mentioned that switching from any one of these options to another is difficult, but switching away from this option is especially painful:
To switch away from popular community-created SDKs, you’ll need to create a unique migration plan for each one, implement it, and support your users through what will likely be a painful and prolonged transition
Language-specific documentation for the new SDKs will need to be written from scratch, as most or all of the community-created reference material won’t apply to your new SDKs
Any major migration process will frustrate and slow down developers, forcing them to work on switching from one SDK or MCP server to another instead of building new things or improving what they’ve already built
The biggest risk and challenge with this approach is the more time your developer community devotes to building SDKs, writing docs, and making MCP servers, the less time and energy they’ll have to build things for your customers
Growth potential
The overall growth potential for this option, both short- and long-term, is low.
In the beginning, you won’t have any SDKs, language-specific docs, or an MCP server, so most developers will be reluctant or unwilling to build things with your API. Inhibiting developers in the early days of your API is the last thing you want to do, and can have serious and potentially disastrous ramifications.
Later, after your community has created one or more projects to interface with your API (which probably won’t happen as quickly as you’d like), the likelihood of running into more of the risks outlined above increases significantly. Just one or two of those risks can significantly harm your growth potential, and you’ll likely run into several over time.
Who this option is best for
If you have extremely limited access to capital (e.g., you’re bootstrapping or have a hobby project) and other low- or no-cost options (like free SDK/docs/MCP generators, as discussed in option four below) aren’t suitable, you may be forced to rely on your developer community to provide key resources.
This approach can also work if your API is uncommonly small and simple, with only a few straightforward endpoints and uncomplicated use cases.
Regardless, it’s important to weigh this option alongside the others outlined below. Unless you’re in a unique or unusual situation, another approach will almost certainly be a better choice. If you do choose this option, it’s important to be aware of, and plan for, all of the risks and challenges covered above.
Option two: hire contractors
Requirements
This option has two core requirements:
Enough capital to pay your contractors
The bandwidth and resources required to manage the relationship with, and expectations of, your contractors
When working with contractors, there are two important things to keep in mind:
First, it will be difficult or impossible to find a single contractor who’s well-versed in multiple programming languages and has experience designing and building APIs, SDKs, and writing docs. If you want to provide SDKs for more than one language, you’ll likely need to hire multiple contractors. If you also want to provide an MCP server, you might be able to “double up” and have one contractor do both an SDK and MCP server in the same language, but you might also need to hire a separate contractor for your MCP solution.
Second, you’ll need to factor in not just the cost of the contractors, but also the cost of the additional overhead required to manage your relationship with them. Make sure you account for the time and resources required to coordinate between your internal teams and the contractors, and coordinate between different contractors if you need to work with more than one.
The overall amount of capital required will vary based on several factors, but will generally correlate with the overall scope of work. If you use contractors to build everything—your API, SDKs, docs, and MCP server—you’re going to spend quite a lot. Even a single SDK can be surprisingly expensive for a contractor to create and maintain over time.
Risks and challenges
APIs, SDKs, docs, and MCP servers are intricate and difficult to get right; finding contractors with the requisite skills and experience may be difficult
Communication barriers may slow things down or lead to undesirable outcomes
You may need to adjust your roadmap or launch plans if your contractors can't deliver on time
You'll need to develop and maintain a quality assurance process to confirm the deliverables provided meet your technical and quality bars, and may need to increase oversight and management beyond what you anticipate to accomplish your goals
If you work with multiple contractors, you'll need to keep them all in sync to maintain consistency, hit major milestones, and avoid fragmentation
Contractors may shift resources from your project to other client work, causing delays and missed deadlines, and the work they do for their other clients is unlikely to benefit you
If you’re working with a contractor to design and build your API, they may require system and infrastructure access that introduces security and privacy risks, especially if you work in a sensitive industry or handle sensitive data
The likelihood of a contractor not working out puts you in a more precarious position than other options where you have more control, like building things in-house or working with a reputable API company
Updating and refining your API, SDKs, docs, and MCP server is an ongoing effort, not a one-off project, so you need to find contractors you're comfortable working with long-term
Growth potential
The growth potential of this option is one of the most difficult to predict, but is generally low to moderate. There are usually multiple contractors involved, their competency may vary, and success will often hinge on how well your organization can manage the projects, relationships, and extra overhead involved.
In most cases, there are two main things that prevent this option from providing high growth potential: low speed and low quality.
Working with contractors often involves delays of one kind or another, and if you’re working with multiple contractors on multiple projects, those delays will compound. Even if the contractors themselves are fast, the overhead of coordinating between them takes extra time and effort.
Regarding quality, it all depends on the contractors you hire. You might get lucky and end up working with speedy professionals who produce great work, but that’s unfortunately the exception rather than the rule.
Who this option is best for
Working with contractors is a good option (and often the only option) when all of the following are true:
You’re unwilling or unable to do this work in-house (option three, below)
You have exceptionally unusual requirements that free generators (option four, below) or API companies (option five, below) can't accommodate
For example, if you need uncommon language support, or if you have an unusual API which doesn't conform to existing standards, contractors might be the best (or only) path forward.
If you’re seriously considering working with contractors and you don’t have exceptionally unusual requirements, working with an API company (option five, below) will almost always be a better option. Working with an API company is cheaper and will yield better and faster results than working with contractors due to economies of scale, the API company’s focus on a specific area of expertise rather than general software development, and the lower overhead of getting API design assistance, SDKs, docs, and an MCP server from a single source rather than multiple third parties.
Option three: build everything yourself
Requirements
Lots of time
Lots of capital
Lots of in-house talent covering all the programming languages you want to support
Management and coordination
Risks and challenges
This option has a very high opportunity cost because it puts a significant drain on your internal technical resources
You'll need to manage and coordinate several technical projects across multiple languages that all need to have uniform quality and feature support, which will be a significant undertaking
Some people decide to fork an open source SDK or MCP generator (see option four, below, for more details) so they don’t have to start from scratch and reinvent the wheel, but keeping a fork up-to-date and maintained is often more work than expected
Due to the high cost of this option, you may not see a worthwhile return on investment
Growth potential
This option has moderate to high growth potential. For most organizations, the growth potential will be moderate due to the high opportunity cost of devoting significant technical resources to API, SDK, docs, and MCP projects.
For a few companies, where the return on investment makes sense, the growth potential can be high. One example of a company like this is Stripe, where the design of their API, SDKs, and docs is of critical importance and needs to be handled with extreme care and attention to detail. (Fun, albeit biased, fact: Stainless was founded by, and employs, many people who worked on Stripe’s API, SDKs, and docs.)
Who this option is best for
This can be a good option for large organizations who can afford, and will yield substantial benefits from, significant investments in their developer ecosystem, especially ones who have non-standard APIs or who require uncommon language support.
Another example of a company who can benefit from this approach is Apple. Keeping their APIs and SDKs in-house and under tight control has significant advantages for them, but the walled-garden approach isn’t appropriate for everyone.
For most organizations currently doing this work in-house, or those planning to do this work internally, using an API company will usually produce better results at a fraction of the cost. In some cases, using free generators may also make more sense. Both of those options are outlined in detail below.
One other factor to consider: if the primary focus of your SDKs is custom business logic, with a relatively small amount of API interface code, it might seem to make sense to create those SDKs on your own. However, API companies and free generators allow you to add custom code, so a hybrid approach where an API company or generator provides robust API logic you don’t have to maintain coupled with your own custom business logic might be the best option.
Option four: use free generators
There are free-to-use generators which, given an OpenAPI specification, will produce SDKs for a variety of programming languages and accompanying documentation. The most popular free generator, at time of writing, is the OpenAPI Generator.
There are also free MCP server generators available, but there’s no clear leader yet due to relatively young age of MCP itself.
Requirements
An OpenAPI spec that accurately and comprehensively describes your API
The technical resources to keep your OpenAPI spec up to date
The technical resources to adopt and incorporate free generator tooling into your workflows for updates, maintenance, debugging, etc.
A system or process for publishing and distributing generated SDKs and your generated MCP server
Risks and challenges
The biggest issue with free generators is the low quality of their output, which will frustrate developers and significantly hinder adoption
Free SDK generators only support a subset of the features that can be described with an OpenAPI spec, and there may not be a free generator that supports all of the features you need (e.g., OAuth, pagination, union types, etc.)
SDKs produced by free generators are often quite buggy (at time of writing, the OpenAPI Generator GitHub project has just over 5,000 open issues, for example)
Free generators are often created and maintained by people who are experts in only a single programming language, so their output is typically only idiomatic for one language; this makes your other SDKs and docs non-intuitive and frustrating to use
The SDK code produced by free generators may not be human-readable, which makes it difficult or impossible for developers to examine how the SDK works when debugging
The SDKs may not provide type safety, which means developers using them will have a harder time catching bugs and errors before they ship
Free generators often produce SDKs which require a lot of dependencies, each of which increases the size of the SDK, introduces another point of failure, and adds additional security risks
MCP server generators are generally immature and lack important features and functionality due to the relatively young age of MCP itself
If you don’t currently maintain an OpenAPI spec, you’ll need to figure out how to generate one and keep it up date as your API changes
You’ll need to rely on support from the maintainers and surrounding community of the free generator(s) you select, which is often hit-or-miss with no guarantees around response time or quality
You may need to make significant changes and adaptations to your API, workflows, and specification to accommodate the free generator(s) you select
You'll be depending on projects which have little or no incentive, financial or otherwise, to help you accomplish your specific goals
You’ll need to research the motivations behind the projects you use to make sure they align as closely as possible with yours, and make sure they have a realistic chance of sticking around long-term
If you choose an open-source generator, you may need to create and maintain your own fork of the project to support the features or workflows you require, which will expose you to many of the risks and challenges of building everything yourself (option three, above)
Growth potential
Free generators are appealing because they're a low cost way to get up and running quickly, but the lack of quality and support for both you and your users means their growth potential is low to moderate.
At best, free generators will produce only functionally adequate results that will fail to excite developers. In the early days, your momentum will stall. Over time, you're likely to hit feature and support dead ends which can derail your plans and cause a lot of frustration.
Who this option is best for
Free generators can make a lot of sense for hobby projects or short-lived experiments, but only when they’re a better fit than the API companies discussed in the next section. Even if you're on a tight budget, you might be able find a commercial API company with a free or low-cost tier that meets your needs and produces better results. If you’re a non-profit or have other special circumstances you may be eligible for significant discounts. It never hurts to ask if you can pay less!
Another situation where free generators can make sense is if you need to support an uncommon programming language that isn't supported by any API company. In such cases, it might make sense to mix and match using free generators and resources created for you by an API company. Just be careful to set the right expectations—both internally and externally—about the different levels of quality and support across the solutions you’re providing.
Option five: work with an API company
There are API companies who can help you with everything you need to take full advantage of the potential of your API, including:
Design a great API or refine the one you already have
Generate high-quality, always up-to-date SDKs and docs for all of the languages you want to support
Generate a robust, cutting-edge, and always up-to-date MCP server for your developers to use
Publish your SDKs to the various package managers
Host your docs and MCP server
The best API companies have many engineers on staff with deep technical knowledge of many programming languages and extensive experience designing, building, and maintaining APIs. The more clients an API company has, and the bigger those clients are, the more value they can provide and funnel into the work they do for you. You can take advantage of that specialized expertise and see high-quality results without distracting or putting a strain on your own technical resources.
Essentially, the best API companies are a one-stop-shop for everything you need to take full advantage of your API, which minimizes overhead and keeps costs down.
Requirements
Requirements vary depending on the company you decide to work with and the level of service you require. In fact, one of the nice things about working with an API company is the flexibility they can provide around requirements.
For example, if you don’t have an API yet, a full-service API company can help you design the best API for your needs, figure out how to create and maintain an accurate OpenAPI spec for it, generate SDKs and docs for you, provide an MCP server, and may even provide hosting.
On the other hand, you may already have an API and an imperfect OpenAPI spec, in which case you can depend on the API company to help you improve your spec and generate SDKs and docs for you.
In short, API companies can generally meet you where you are and provide as little or as much help as you need.
Risks and challenges
An API company’s pricing may change over time, although pricing changes usually aren’t extreme, and in some cases pricing may even go down
Once you provide SDKs, docs, and other resources to your developers, it's very difficult to switch, so you’ll need to perform a lot of due diligence up front to select the right API company for your needs
The next post in this series will help you pick the right API company; subscribe now so you don’t miss it!
Worst case scenario: the API company you’re working with goes out of business or exits the market
To mitigate this risk, research the health and potential longevity of any API company you consider working with, check to see if they have several large and independent clients, confirm you’ll own the assets they create for you, and make sure it would be practical to maintain those assets in the company’s absence (e.g., are the SDKs human-readable and easy to modify, or would they be a nightmare to maintain on their own?)
Growth potential
This option has high growth potential. If you select the right API company, the knowledge and experience they provide will allow you to create the best API possible, seamlessly integrate SDK, docs, and MCP server generation into your existing workflows, and keep the drain on your internal technical resources to a minimum.
With a high-quality API, SDKs, docs, and MCP server, you can provide developers with a fantastic experience and unlock a great deal of potential growth you wouldn’t otherwise have access to.
Who this option is best for
API companies, by design, are the best choice for most organizations who want to take full advantage of their API. Startups, organizations prioritizing growth, and enterprises can usually benefit from the knowledge and solutions API companies have to offer.
If you have exceptionally unusual requirements, a non-standard API, or other uncommon considerations an API company may not be the best fit. In these cases it might still be worth having a conversation with the support or sales team at an API company to confirm the mismatch. In some cases, you may be able to get early access to upcoming features or solutions which, will not advertised on the API company’s site, may bridge an important gap.
Next steps
Figuring out how to provide a great API along with great SDKs, docs, and an MCP server can be a daunting challenge. Hopefully, we’ve provided you with some clarity about which option is best for you. But now what?
If you decide to depend on your community, hire contractors, build everything in-house, or use free generators, we recommend you create a detailed plan that accounts for all of the risks and challenges outlined above. Even if a particular risk seems unlikely, you should still have a contingency plan in place.
If you want to work with an API company we would love to work with you, and you can get started right away, but you shouldn’t decide on an API company without doing a lot of due diligence. This is the first post in a series, and the following posts will help you pick the right API company to work with. Subscribe now so you don't miss them!
Yes, we’re an API company, but we promise our upcoming posts won't just be “pick us” stretched out to a thousand words. Our goal is to help you make the best choice for your situation, even if that means you don't work with us.
Ultimately, we want to help everyone create the best APIs possible and foster their use by making them a joy to use. APIs, and the ecosystems surrounding them (SDKs, docs, MCP servers, etc.), are the infrastructure that increasingly binds the world together. The healthier that infrastructure is, the more we can all build on top of it.
If you have any questions or feedback about this post, or want to chat about your API, SDKs, docs, or MCP server please let us know, we’re here to help!
Originally posted
Dec 11, 2025