You've successfully subscribed to Routable Blog
Great! Next, complete checkout for full access to Routable Blog
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.

Why fintechs can’t scale without a developer-first mindset

Why fintechs can’t scale without a developer-first mindset

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.

Stripe’s success with a developer-first approach

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.

The three core elements of a developer-first mindset

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.

1. Focusing on flexibility

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.

2. Eliminating breaking changes

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.

3. Providing thorough documentation

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.

Adopt a developer-first mindset from the very beginning

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.


Learn more about Routable and our easy-to-use API.

Ready for a demo?

Routable Schedule a Demo

1

We reach out to quickly learn about your needs.

Routable Schedule a Demo

2

We show you the goods in the first 2 minutes of the demo.

Routable Schedule a Demo

3

We work with you to make onboarding a success.