Payroll system
Back to our workIn brief:
- System with more than 150,000 freelancers
- More than 1 million € in payments every month
- Onboarding over 5,000 new freelancers every month
- Built with Laravel, Filament in combination with MySQL, ElasticSearch, Redis
Why this project?
One of our regular partners is a payroll company that recruits people online for various activities.
Their old payroll system was built in a self-invented framework. Fortunately, according to an MVC model. But the fact that it was a proprietary framework made it very difficult to build new features and almost impossible to onboard new developers.
Of course, the system was very dependent on one specific developer. The need arose to create a new payrolling system.
So we were asked whether we could develop a new system, built on open source techniques. We would take into account that it should be simpler to build new features, and make it easier to introduce new developers to the project.
What has been built?
In addition to being a payrolling system, the system that we have built is also a system that keeps track of exactly how much work is being done and by whom.
Every month we read in more than 10 million data points to determine the exact compensation of each freelancer. We automatically create payment files for the administration where we pay out more than € 1 million per month to the freelancers.
The turnover of freelancers is relatively high. That's why we onboard 5,000 new freelancers almost every month. This Applicant Tracking process is also completely built in the same system.
Together with our partner, we try to build more and more features to ensure that they have to perform as few repetitive tasks as possible for managing the operation. That is why we are in constant consultation to see how we can make existing functionalities better, more efficient and more robust.
Which tech has been used?
We have chosen to work with Laravel, Filament and where necessary other database techniques such as Redis and ElasticSearch.
That way we were able to quickly set up a minimal viable product where we could quickly add features. Much of the system is simply CRUD.
Unfortunately, at some point MySQL turned out not to be the right solution for many statistics and we partly switched to ElasticSearch. Now we are again faced with the question, is that still the right solution?
What are the future plans?
This is now a project that has been running for more than two years, with a backlog that we can fill the coming years with. Fortunately, we are given the space to not only add features, but also choose to make the application more scalable and to work on the architecture.
Due to its size, this project has now grown into an application with multiple functions in one tool. Functionality and responsibilities that, in our view, we can now better split up, in other words it is now a monolith.
We want to convert this to different services, where we will clearly divide the responsibilities of the application. The right functionalities in the right service. We are now busy outlining that architecture and help is always welcome!