Replacing a commercial ATS with a HUGO based self development within 24hours

Sometimes, I need a break to take my mind off of SAP, Focused Build and the such. As a huge tech fan, I love to use these breaks to explore the great ideas and products out there. This time, I came across HUGO and decided to put it to good use for us from the get-go.

TL;DR — Most commercial applicant tracking systems (ATS) are IMHO massively overpriced, have a huge bunch of useless features and are severely limited when it comes to the needs of scaling up small companies. So I developed our own system with HUGO, getform.io and Airtable in less than 24 hours.

The problem

Admittedly, some problems with our previous systems may be partially our own fault. We use a not-so-standard TLD .works for our company, and despite it being recognized by the ICANN as a valid domain ending, surprisingly many online forms and software vendors simply can’t deal with our domain. I’m guessing it starts with simple, outdated REGEX pattern requirements and their reliance on other tools and solutions who have similar problems.

This led to an issue where our previous, commercial ATS failed to send out notifications to our team when a new applicant submitted their CV. Since we don’t have a dedicated HR team who track these things on a daily basis, this situation has led to a number of applications gone unanswered and us missing opportunities to hire potentially great team members. (If you were one of those applicants, I sincerely apologize!)

The requirements

As a company we are at a crucial point in time – our team is quite busy and the workload for the foreseeable future is promising growth. With that, we need to find new team members to join our side in the trenches.

As most of our team is constantly on the road, consulting our customers, we need to be able to review and managed the hiring process on the fly. We need a system that works with us proactively.
Another requirement is a portal for applicants to not only see jobs in different locations, but also be able to read them in the local language and English.
Next, an applicant should be able to easily apply for a job, and not need to deal with a complex, multistep form. Name, Contact Details, CV – That’s it. At this point we don’t care about age, gender, marital status, family matters or immigration status.
And finally, we want to be able to introduce our company in a more authentic experience, matching our design language and structural wishes.

Research

Armed with these requirements, I started searching tools that are available in the market today – our doctrine is to keep our own developments limited as far as reasonable. At the same time, we don’t feel like paying $100 per month to be allowed to publish three jobs on a given platform is fair, nor justified. None of the solutions found ticked all our requirements – I became frustrated.

As most of the web, we use wordpress as our primary CMS, but with even more plugins and extensions it feels more and more like a huge bloat for a CMS. So I wanted to avoid using it for our job platform, as here too, I haven’t found a plugin that matches all the needs we have toward an ATS. It was time to think outside the box: I had come across HUGO after I found a very interesting, fast loading website, and I used builtwith.com to analyse what technologies drive it.

In a nutshell HUGO is a static site generator, that turns markdown content into fast loading, HTML sites. Designing a theme for it to use is straightforward and with its ability to define custom parameters or variables it really is a perfect tool to manage less frequented sites with static content.
It comes with multi language support out of the box and is easily managed with a simple configuration file.

The solution

I was hooked. HUGO seems like an amazing product with so many potential applications and use cases. After skimming through the docs, I downloaded HUGO, spun up a new site in seconds and found a simple template to use as a blueprint.

HUGO new site jobs.blue.works

Thanks to our design language being fairly well standardized and documented, I quickly adjusted the look and feel to support or visual appearance. Next I added custom post types for our job ads and defined a number of custom variables such as Job ID, Job Level, Location, Start Date, etc. I ended up with a simple template that is easy to fill out and use to publish new openings at our company.

Next, I needed to implement the application form. Here I opted to go for getforms.io, as suggested by Mertcan Yücel. After a quick signup and setting up our endpoint, the basic framework for our application form was quickly setup in HUGO. Simple Javascript passes some key variables from the job ad straight to the form, so applicants don’t need to worry about selecting a job or we won’t need to figure out for which positions someone applied for. I also added a thank you page, where our applicants would be redirected to after a successful submission.

Once the form is submitted, the workflow continues. The data collected by our ATS is forwarded to an Airtable base that serves as our new primary storage location for our applications. Within minutes I set up a new table, a kanban board with the different steps of our application funnel and a an overview dashboard, which I added to Microsoft Teams as a website for us to have a quick overview of our application processes.

Finally, I setup an automation that would send a notification to the hiring manager in Microsoft Teams every time a new application comes in.

Done is our custom job portal. It took me all of 24 hours to do, and so far I am very pleased with the results.

And with Getforms and Airtable, our ATS price tag dropped from $100/month to 20. Considerable savings if you ask me, plus it will do the workflow we want it to, and not the other way around.

Deploying our solution

Next I need to consider how to deploy and managed the site. Building the site after changes is simple enough. However, getting the site onto a web server for the world to reach, needs to be simple and easy to manage.

I initialised a Git repo in the public folder, the directory HUGO creates the built code in. After a build, the code then is pushed to a private Repo on github, from where our web server pulls the changes and published them accordingly.

From a technical perspective simple enough.

However, and this is a bit a bigger one, managing and publishing jobs needs to be easy. Not everyone on our team is a coder, or much less savvy with Git or even Markdown. And requiring someone specific in the team to manage changes is also only a short term solution. Here my research continues, but some of the headless CMS solutions out there have caught my attention. I will dig deeper into this, when I find another 24 hours, but for now visit jobs.blue.works to see the outcome of my work.