A 100% unfiltered blog straight outta
NewsroomProduct StudioInside CurveCompiled

The history of tech at Curve

By Matthew Collinge - CTO26 Jul 2021
5 min read

The story of Curve began about 5 years ago. This is the story of Curve Engineering, where it all began. Here we lay out what tech stack was used and how we have evolved to our 100 plus strong team. 

Team structure evolved with service ownership

Our team structure was very different to what we see today. Initially it was one team, with a few contractors. As time went on, the size of the team grew and then split to focus engineering efforts more efficiently. Responsibilities split with the teams. Initially a singular developer could be responsible for a whole service, so if someone asked for a new feature, it would be put into whatever service they were familiar with or “owned”. This led to business logic being scattered out and with multiple engineers contributing to core parts of the application at the same time. This led to developers having less of an understanding of the overall system due to its chaotic nature.

Some of those services still exist and are almost looked down upon because of their history. It was sloppy. The onboarding of engineers at that point wasn’t easy. Multiple people were developing in their own ways, and on the services they knew best. This was unproductive as services were not standardised, they used different libraries, they had different behaviour. It led to a lot of frustration.

How Engineering grew up

Yet, the benefit of having such a small team was we had a full quorum for meetings such as design authority, everyone was in there. You could get everyone to buy into and share ideas. It became more challenging to share those ideas more broadly as the team grew.  Even if someone was not directly involved in a project, they had a broad understanding of what was happening.

That's where discussion around standardisation came up. These led to design sessions around how the structure of the application should look like. Starting from the structure, the naming conventions, and what they should represent. That's where we come up with the internal folder, that holds all the business logic, and then you would have the repository folder for the concrete implementation of the database. Testing was also discussed, unit vs integration. Then came documentation to describe all these decisions.

The aim was to have a good solid foundation with standards and best practices to help guide everyone. But what really shaped our best practices were the developers who were building things in parallel, who had big ideas, who brought new ideas and solutions to the table.

Starting off as a small team, there was a lot of early adoption, including new tools such as Istio. We were willing to try new things, move fast and break things. Today, we have to be a lot more sensible. We have targets to meet in terms of stability. The company has grown up and we've had to grow up. We can still experiment, but we have to ensure our customers have a stable and reliable service at the same time. 

Language evolution

As business logic and ownership of services was scattered, a conversation around language arose.  Curve started as a PHP monolith. It was chaotic; the system would work on some people’s machines, but not on others.  A group of engineers didn’t want to work on PHP anymore and were eyeballing new languages. 

Consideration went into Python, Go, Java, Rust and the team finally settled on Go. The reason behind this was that it is a simple language, easy to deploy, quite easy to learn, and it’s fast. It also comes with a lot of tooling such as Go Kits, that help plug in components to deploy microservices and make it work out-of-the-box with http server and middlewares.


Initially we had dedicated machines for each service. The Go services were the first to be deployed in Kubernetes. CI at the time was Jenkins, their EC2 instances deployed with the code and load balancers in front of them. But quite soon afterwards, we had Kubernetes being tried with the Go apps first and then rolled out Kubernetes fully. Docker was there from the beginning with the PHP apps. The trajectory we had of Microservices, then Go and then Kubernetes made sense. It’s almost evolutionary.

Looking forward

The future for engineering at Curve is to build on our growing number of Go services. This will allow engineers and the Product team to rapidly deploy new features and services for customers whilst maintaining a high standard of reliability, availability and security.

Building a new service should be simple; using standardised libraries and paths that enable us to concentrate on the business logic and features, rather than the plumbing. Deployments to our Kubernetes cluster should be frictionless and future upgrades of libraries, drivers and underlying infrastructure will be continuous, empowering our engineers with the applications we build. 

Clear ownership of services, observability tooling to chart the health of services and their inter-relationships will allow for profound understanding of how our services provide value to the customer.

These tasks are facilitated by our enablement teams who are growing in number and are empowering our engineers to work better, more efficiently and with more confidence. 

Looking forward, our engineers should be self assured, continuously learning and building the best. 




Money talk with Elizabeth Boampong


Curve X: why we're introducing a new tier


How to protect yourself against fraudsters


Easy ways to save on every holiday this year

Curve UK Ltd, registered in England and Wales, #09523903

Copyright - 2021 © Curve UK Limited. 

The Curve Card, the Samsung Pay+ and the E-money related to these cards is issued in the UK by Curve UK Limited, authorised and regulated by the Financial Conduct Authority to issue electronic money (firm reference number 900926). Curve UK Limited is registered in England and Wales, United Kingdom (company reference number: 09523903) and located at 15-19 Bloomsbury Way, Holborn, London, United Kingdom, WC1A 2TH. 

Curve Flex is provided in the UK by Curve Credit Limited. Curve UK Limited is an introducer appointed representative of Curve Credit Limited, which is authorised and regulated by the Financial Conduct Authority (firm reference number 925447). Curve Credit Limited is registered in England and Wales, United Kingdom (company reference number: 12464458) and located at 15-19 Bloomsbury Way, Holborn, London, United Kingdom, WC1A 2TH.

The Curve Card and the e-money related to cards issued in the EEA is issued by Curve Europe UAB, authorised in Lithuania by the Bank of Lithuania (electronic money institution license No. 73 issued on 22 of October, 2020). The Curve Card and Samsung Pay+ are issued pursuant to license by Mastercard International Inc. Mastercard® is a registered trademark of Mastercard International Incorporated. Curve Europe UAB is registered in Lithuania (company reference number: 305626541) and located at Jogailos g. 9, LT-01116 Vilnius.

Third Party Providers (TPPs) can now connect to Curve’s dedicated API interface for providing aggregation and other services to customers. You can find the access details for using the testing facility (sandbox) in the documentation. Get started with TPP onboarding.