Analysts project the Global Fintech Market will grow at a compound annual growth rate of around 20% over the next four years, reaching a market value of $305 billion by 2025. Fintech innovation is happening all over the world, but unfortunately, many fintechs are making the same mistake: failing to adopt a developer-first mindset.
One might think that developers are so tech-savvy that they should be able to integrate whatever fintech product their company wants to use, and this is true to an extent. But while developers are often tech-savvy by nature, they’re also just like everyone else in that they have their own preferences for the products they use. Developers are highly influential stakeholders: If they don’t like your product, they’re going to push their company to use a competing product instead. To win over these key decision makers, it’s crucial that fintechs prioritize their developer preferences in order to scale and grow long-term.
In terms of fintechs that have embraced a developer-first mindset, infrastructure fintechs tend to be good examples. Infrastructure fintechs are companies selling financial products that can be embedded into various applications. These are often the underlying financial technologies that work behind the scenes to power the financial services that consumers and businesses rely on every day.
For example, Stripe is a very popular and successful infrastructure fintech — it sells payment products that are entirely white-labeled and embedded. Early on, Stripe embraced a developer-first mindset because it recognized that developers are the ones who integrate its products. Stripe built its Application Programming Interface (API) to be flexible and developer-friendly, and that approach has helped it scale and become the market leader it is today.
Non-infrastructure fintechs should also take note. These fintechs often sell their services directly to consumers (e.g., budgeting apps or brokerage accounts) and can emulate Stripe’s developer-first approach in order to drive long-term growth as well.
So, what exactly constitutes a developer-first mindset? The core elements include focusing on flexibility, eliminating breaking changes and providing thorough documentation. Here, I’ll explain each of these practices and how to implement them.
An API is essentially a set of definitions and protocols for developing and integrating application software. It’s key for automating certain processes, which should be a focus for every fintech that wants to delight current customers while growing its market share. Many fintechs deliver their products through an API, and making their API flexible is a must for winning over developers. APIs should easily integrate with other systems, and fintechs should build their APIs to function similarly to comparable products rather than reinventing the wheel.
An easy way to ensure your API is flexible is to pressure-test it with as many developers as you can. Rather than relying solely on in-house developers that are intimately familiar with your systems, source feedback from external developers as often as possible. This will ensure that your API is flexible enough to plug into a range of systems for a variety of use cases — both of which are crucial for scaling up market.
A breaking change is one of the most frustrating things developers encounter when using APIs. It happens when a change is made to an API that can break a user’s application, and it typically involves modifying or removing existing elements of that API. Examples of this could include removing a response field or modifying required parameters.
It might sound like breaking changes are unavoidable if you want to update an API’s functionality or improve performance, but there are actually myriad ways to avoid it. Rather than modify or remove certain resources, response fields or parameters, focus on improving functionality by adding new elements, as additive changes are far less likely to result in a break. Additionally, robust internal testing for accidental breaking changes is key for avoiding breaks and keeping developers happy.
With enough foresight and planning, it’s possible to update an API’s functionality without causing a breaking change. (I’m proud to say that Routable hasn’t had a breaking change in over two years.)
When you need to make a significant update that could result in a break, implement a versioning system instead. This entails creating a new version of your API so that developers can use it to gain access to the latest updates. The previous version, however, is still available so that developers using that version will not incur a break. From there, proactively communicate the update to your users and let them know when you’ll be deprecating the previous version. This gives developers time to plan accordingly and protect their applications, which goes a long way in keeping them happy.
Providing thorough documentation is probably the most important element of a developer-first mindset. API documentation is the technical content that documents an API, providing clear instructions for using and integrating the API, along with updates on new versions or retirement.
Developers expect to see the following from API documentation:
Examples of use cases
Request and response parameters
Examples of commonly used coding languages
An explanation for each API request
Examples and instructions for troubleshooting common issues
Providing thorough documentation for every element of your API is important, but I urge fintechs to pay particular attention to documenting how the various functions of your API relate to the end use case. When dealing with financial services, you have a lot of sensitive information at play — and this goes well beyond fintechs that actually move money.
For example, a company that automates bookkeeping reconciliation isn’t actually touching the funds, but they do affect their clients’ books. This is why it’s so important that developers know the finance terms and functionality that correspond with each element of the API. With proper documentation, developers can use your API with confidence and resolve the bulk of any issues they encounter on their own, saving both you and the developer time and money.
It’s easy to overlook developer needs when building a fintech product, but it's absolutely critical for fintechs if they want to scale. I urge you to adopt a developer-first mindset from the get-go because the unfortunate reality is that it’s extremely difficult to become developer-first if you weren’t started that way.
You can think of it in the same way as city infrastructure with regard to transportation — the city of Los Angeles was not built with public transportation in mind, and despite decades of efforts, it remains a car-first city. Knowing that developers are key decision makers with regard to integrating fintech products, it’s essential to prioritize their needs. As we’ve seen with Stripe and many others, adopting a developer-first mindset today will pay off for years to come.
A Routable manager shares lessons learned as part of an engineering team that has exploded in size in a short time.
Business payments are a lot like pull requests—the mechanism software engineers use to alert their team about changes to code and get it reviewed before it’s deployed.