Firmin Zocchetto, founder and CEO of PayFit, explains why PayFit decided on the unusual move of creating its own coding language rather than using an open source language.

At PayFit, we are trying to make a HR Manager’s daily life a lot simpler. Replacing clunky legacy systems with smart, accurate and automatic software solutions. We now employ over 200 people, but it all started with an obsession with our product and – importantly – the technology that underpins it.

To achieve our ambitious goals, we decided to develop our own internal technologies rather than to copy-and-paste existing solutions. As part of this, we developed our own coding language: JetLang.

Why did we do it? Because we need to separate our business logic from the code used for software engineering. Not every software company needs to abstract its business logic from its code in this way. However, PayFit does. Why? While the HRIS (human resource information system) part of the product is the same for all countries, we often need to completely change the payroll element of our product for a new market.

Payroll – and the laws and rules governing it – can be substantially different from country to country. The laws in Germany are vastly different to the legislation in France (our original market), and the laws in the UK are different again. As the laws are so markedly different, we need the ability to alter the functionality of PayFit, so it can best serve HR people, whether they are in Bedfordshire, Biarritz, or Baden-Baden.

In other software as a service (SaaS) applications, updates relating to product often involve several developers, who know the codebase and the product like the back of their hand. This takes time, and is prone to human error.

When ‘JetLang Masters’ make a critical update, they cannot negatively impact other countries, nor the HRIS element of PayFit’s solution. They can only impact the payroll aspect, and therefore cannot paralyse the other teams, or other parts of the product.

By separating our business logic and our code, we have made PayFit an inherently more ‘scalable’ product. Sure, we could have asked software engineers to code laws and social agreements, but this would have quickly become impossible to maintain. End-users tend to suffer if a company takes this short-termist view. Quick fixes pile up and undermine the original product, making it complex, slow and unusable.

This is why we developed our own language. In so doing, we have made it far simpler to increase the possibilities of PayFit across new markets and geographies. This enables us to abstract all of the business logic – the stuff we need to alter for new markets – without bringing on a crew of developers, disturbing our code, in a way that is simple, automatic, testable and powerful.

The result is a simplified language that enables HR professionals and developers to better use the project. Payroll teams will be able to create the pages and the logic, and to generate lists, modals and make complex calculations. Developers will be able to focus on UI, performance or security without busying themselves with business logic.

Would we recommend that other software companies develop their own language? We only did so as we had a specific need: we needed our product to serve users in very different ways, depending on the market. Therefore, we needed to abstract business logic from the software engineering code.

If you are creating a SaaS company – and you are operating in a market that is heavily regulated, and is therefore operationally different, at a national level – then creating your own language may be the best route to take.