Printed letters, smart emails and modern blog stacks at Compte CO2

In short

When I arrived at Compte CO2, the company was launching new products and needed a total revamp of all its frontend styles. With the help of a graphic designer we started a six month marathon, redoing everything from the main website to the blog, but also email templates and print styles for printed bank documents.

This short mission was a massive step forward in my career, as I was able to learn a lot about moderm JavaScript tooling and frameworks. I self-studied React and NodeJS before starting, and developed my first official component library for a client.

All those efforts resulted in a more cohesive vision for the company and a greater understanding of modern web development practices for me.

The client(s)

Compte CO2 is a banking startup dedicated to fighting climate change. To do so, it has its own money, the CO2, who's value is indexed on the official CO2 gaz price. Clients opening a bank account can either pay in Euros or in CO2.

Compte CO2 had a fairly recent custom made banking API entirely in NodeJS. Its website was made with Wordpress, and its mobile apps were created using React Native. React was well liked at the company and the CTO's wish was to invest more into it for all parts of the organization.

The company headcount was small with only 6 people.

The problem(s)

When I joined in February 2018, the company was just issuing its first credit cards and had just launched its app on iOS and Android devices.

Both came with a new design that hadn't been applied to the web. The two main enginers were busy working on banking features and updates for the apps, with no time for the redesign of the frontends, thus the reason I was hired.

With a deadline set to September 2018, there was very little time and a lot to do.

The solution(s)

As many other companies that grew fast, Compte CO2 didn't have design guidelines or a graphical chart. My first mission was, obviously, to contact the freelance graphic designer responsible for the new design, organize his work as reusable assets, and try to create design tokens. What are the main colors, the fonts, their sizes? Do we have a bank of images? Packshots of our credit card? Screen captures of our smartphone apps?

Once it was done, I noticed that two of my colleagues were losing a ton of time manually editing documents in word. Those letters were super important: we glued the credit card on them before sending them to the client. This is when I realized we didn't have an automated way of generating print documents directly from our API. That was the second mission I took upon myself.

Once I had access to our clients API, I created a new NodeJS app that used Puppeteer, a library which provides a high-level API to control headless Chrome. Using this headless Chrome, I generated virtual pages using custom made HTML/CSS templates and our clients data, then saved them as a PDF file using the browser print API. I also programmed an automated deletion after some time, to avoid stocking too many files.

Of course it meant developing templates made uniquely for print, which is not the most... exciting stuff? But it proved very useful a few days later, when I learned we also didn't have printable account statements too, a feature that was very often requested by clients. I spent a few more days on this before giving it back to our main backend enginer who implemented it in our mobile applications.


I was then supposed to start working on the website, but it turned out the design was not finished. To avoid wasting time, I tackled a new challenge: emails. The company had a lot of templates for things like real time payments, money transfers, and general communication.

Our system was built on Mailjet's API, and so no massive rework was to be expected on the backend. But on the frontend, the new graphical chart, with its use of SVG, gradients and custom fonts was extremely tricky to put into email templates. It is not well known outside of frontend development but most mail providers, even famous ones like Gmail, restrict the HTML and CSS rules that can be used on their platform.

Sometimes it's impossible to use a gradient, sometimes it's a background image, or a custom font. It becomes a puzzle when you have to provide readable email to clients. That's when I learned about progressive enhancement and degradation in frontend development. It's a way of coding in HTML and CSS that allows the design to look perfect on most modern platforms, and degrade in a controlled way for others.

Mailjet has an amazing feature which allows to simulate an email with the HTML and CSS constraints of most mainstream mail providers, apps and operating systems. Using this, I was able to create new and shinny templates that were still enjoyable and practical for people with outdated software and hardware.


And finally the website! As we were running out of time, the webdesigner could only deliver classic, desktop templates. Our CTO wanted to part ways with Wordpress, at least for the frontend, and asked me to work on staticaly generated website. At the time the new cool kid in town was Gatsby, a static site generator built upon React and GraphQL.

While the CTO was busy turning our Wordpress into a headless CMS and connecting it to Gatsby, I started coding as the deadline was approaching. I soon realized I was going too fast and shooting myself in the foot, duplicating too much code. I took a step back to analyze the designs that were delivered, trying to detect patterns, identify common components, their variations, and organize them in categories.

Once I was more confident, I restarted developing the React components, and it was a net positive for reusability and performance. It allowed the creation of a very interactive homepage, full of amusing widgets, converters and galeries. Performances were way better than the original Wordpress website with things like lazy loading and preload rules, rising our SEO scores even higher. When the homepage was done, I worked on the blog, a very important source of trafic for us because of its quality content.

It was going smooth on the React side, but we faced difficulties with Gatsby. The framework was in version 1 at the time, and things like static queries were not yet implemented, resulting in a lot of props for things like basic images. Connecting our frontend to Wordpress with Graphql took a lot of time, as data from Wordpress was not always available and needed to be reworked. Weeks of works were lost due to these constraints, which resulted in more stress and pressure.

In the end I wasn't able to see the website completely finished by the time my mission ended in August 2018. I left the company after delivering all the components necessary to build the expected pages, but it took several more weeks for our CTO to finish it.

Lesson(s) learned


Initially published: August 25th, 2021
Generated: November 12th, 2021