Recharge.com: Added value as a permanent IT partner
If your business is growing rapidly, you'll sometimes run out of in-house developers. Here's how we add manpower and also bring a lot of expertise.
- Ruby on Rails
Bauke, Ewout, Roland and Robin worked on this project
The Dutch FinTech company Recharge.com sells branded payments. Think of calling credit, prepaid credit cards, gift cards, gaming credits, name it and Recharge has an option for it. They do this in 150 different countries with all kinds of different payment methods. When we started working with them, they had 30 employees and now that has grown to more than 100 people. That’s a big scale-up!
Barriers to Growth
When you grow fast, it is sometimes difficult to keep up with your own growth.
At Recharge, scalability is in their DNA. hThink of increasing visitor numbers, payment methods, product range, employees and countries in which they are available. To be able to grow both inside and outside the EU, there had to be support for multiple languages and multiple products. In a search for a way to rapidly scale development capacity (besides hiring freelancers), they wanted to see if they could work with a remote team with just as much affinity for online scalability. Enter 10KB!
Our knowledge and expertise
We looked for the areas of expertise that were underrepresented in-house, so that we know where we can be of most value.
Some of our core qualities are exactly what Recharge needed. For example, we are specialized in DevOps and we know a lot about rolling out web applications. Combine that with our experience in the field of performance and we have everything in-house to work together on a high-traffic application.
The best of both worlds
Today, the SysOps workspace mainly takes place in the cloud. This makes the tech infrastructure extremely scalable. A system administrator no longer needs to manage physical servers and hard drives, but encrypts servers, hard drives and databases in the cloud. On the other hand, you have developers who are concerned with building applications. The moment an application goes live, it is often no longer as simple as 'just uploading'. That application has to communicate with a complicated online infrastructure. As a result, you increasingly need a SysOps engineer who understands the infrastructure and a developer who understands the application. They will then make a deployment together. The (better) alternative is one DevOps engineer, who understands both. The moment you want to improve something in your application, a SysOps engineer will (by default) try to solve it with the infrastructure, when that might not be the best choice. At the same time a developer will try to solve it in his application, while that may not be the best choice. If you have someone who is experienced in DevOps, who therefore has sufficient knowledge of both domains to know what the possibilities are of the gray area in the middle, you can justify those choices much better. One person can then, for example, make a deployment automation, because they know enough about the application and know enough about the infrastructure to be able to tackle that entire area.
Stable software, even with thousands of visitors per day
With hundreds of visitor requests coming in every minute, it's difficult (practically impossible) for a single server to track and display text, photos, videos, and application data at the speed most users are used to. In addition, your software must be able to withstand a lot more. If something goes wrong with 1% of your visitors, then that is not so bad for a visitor number of 500. However, if you have a high number of visitors such as Recharge, that means hundreds of people per day who all need to have a smooth experience.
The challenges of high-traffic websites
We have a lot of experience with increasing the speed of websites. How we do that has to do with thousands of things: that you ask the right questions to the database in the right way, that you compress your assets in the right way, that your images are small enough, that you only load the code you actually need at that moment, etc. etc. There is a whole laundry list to ensure that your application is fast. While we could tinker with a number of things at random, our first questions are always: why is it slow? Why isn't it fast? What is the biggest contribution? So we start with the parts that have the biggest impact on speed. Every second that your website gets faster, you will gain an increase of conversion of 2% on average. So you can imagine that it generates a lot of money for Recharge if they have a fast website.
Thinking about your environment
Because Recharge wants to scale globally, you should also consider the (global) infrastructure of the internet in addition to your software. In the Netherlands, everyone has at least 50 Mb of internet (mostly through a fiber optic cable), which makes it a little less interesting what the speed of your website is and how compressed everything is. About 80% of the world only has access to the internet on their mobile phone. And that phone is not the latest Samsung or iPhone, but rather a phone that is five years old. That's just what people have in countries like Mexico and India, while those are gigantic markets where a lot of money can be made. So you have to make sure it works there too. Even if you consider, for example, where you place servers. You can just put them in Europe, but that will be slow for someone in Chile. These are interesting issues that we like to deal with.
Permanent IT partner
We are good at quickly mastering a large project and can therefore get to work immediately. For a client, this has the great advantage that results can be seen quickly. Recharge keeps coming back to us, because they are very satisfied with what we deliver, but also with the way we work. In this way we communicate clearly about feasibility and we try to think along proactively. As a result, we come up with new ideas, adjustments and we give feedback. This is one of the reasons why we have been a reliable IT partner for years!