How we Built our Offsetting Marketplace

Pledge’s offsetting marketplace forms a core part of our product offer. It enables our clients to access vetted carbon projects and new carbon removal technologies on one platform and to neutralise their unavoidable emissions.

Today we speak to Bertrand Camara, one of our fullstack software engineers, about how the platform was built, its features and its user interface. We also find out what challenges were encountered by the team during the development process and how they were overcome. If you’re an engineer looking for a new challenge and find that this interview has piqued your interest in Pledge, take a look at our open positions below.

Could you tell us about the offsetting platform that you’ve been working on? What is it designed to do?

It is essentially a marketplace that showcases a number of portfolios of carbon projects that we work with. We take a portfolio approach to enable customers to select from a variety of different criteria, while also meeting their budget. We give them an at-a-glance view of what each project does, its location, which Sustainable Development Goals it relates to, the availability of the offsets and the price range. We also include guides to explain some of the more technical aspects of offsetting.

What challenges did you come across during the development process?

To me the first challenge was to understand the mechanics of the offsetting market. Initially, it can seem like a bit of a minefield — every detail matters, from the technical aspects of the projects, their science and methodologies, all the way through to the project developers behind them, the registries, credits, retirement processes, compliance and more. The real challenge is to take all that and to turn it into a simple, user-friendly platform.

Why did you opt for an event-sourced system for the offsetting platform and what benefits has it provided you?

We wanted to build a platform that can promote and facilitate transparency, which is particularly important for auditing. Event sourcing is a great way to see not just the current status of the platform but also how we got there. Having all this is very reassuring because in case something goes wrong — let’s say a bug or an infrastructure failure — we have all the required context to time travel and recover.

Secondly, with a system that is asynchronous first, we can properly separate domains and responsibilities, making services more isolated and autonomous. This adds to the stability and fault-tolerance of the platform.

How much freedom did you have in the technical choices and the process?

I had loads of freedom to discover and propose solutions, but before choices were made we always involved other team members or even other squads depending on the scope of the task at hand. At Pledge this dynamic is really healthy, and because of the horizontal and collaborative culture, most decision-making is a team effort. It means that there is much less margin for error, which of course benefits our users.

If you had to do it again, what would change?

At the beginning I think I put too much effort into implementing things that I thought had to be enterprise-ready fast. I was the only engineer for some time and went straight into delivery mode. I used the technology and patterns that were already in place without taking the time to understand the bigger picture.

After several weeks we could see that other patterns would work better. This was fine of course, as Martin Fowler said, “it can take a year of programming on a project before you understand what the best design approach should have been.” I’m pleased with the end result, but if I could go back, I’d approach things in a more prototype manner to speed up learning. I’d be less strict with things such as the code coverage, layering and componentisation.

How is the squad organised? How is it integrated with Pledge’s other tools?

The squad is organised as a product team, multiskilled and cross- functional. At the moment it comprises a subject-matter expert, two engineers, a product designer and a product manager. We work in Agile, leaning on Extreme Programming. Features always go through discovery and design phases before landing on the backlog, which is constantly evaluated and prioritised.

We integrate a lot with other tools at Pledge — clients use our measurement tool to calculate their carbon footprint and understand their top emitters, before making reduction measures and offsetting their unavoidable emissions through our marketplace. Our measurement squad works on the calculation part of our product. You can also use the marketplace in isolation, if you’ve measured your carbon footprint elsewhere and you want to make a bulk offset purchase, or you can embed offsetting into your user journeys.

The features we develop both on the API and apps also depend a lot on the work of the platform squad. In summary, there is a lot of cross-team collaboration and support, and we have a daily engineering standup to help us keep things aligned.

And what are you most excited about when it comes to the offsetting platform?

We’re launching the platform imminently, so we’re very excited about companies beginning to use it! Although we’ve conducted extensive testing, we’re always open to feedback which would help us to improve it even further and make it best suited to the needs of our users.

Pledge is on the lookout for new team members

Does it sound like the perfect workplace for you? We’re hiring for a range of roles, including a Full-Stack Engineer and a Senior Full-Stack Engineer. Take a look at all our vacancies here.