Our work

How we reduced our HR tool costs by 84% with low code.

ProductDock successfully replaced an expensive and inadequate applicant tracking system with a low-code custom solution.

This strategic move aimed to address specific challenges related to unnecessary costs, missing features, and a mismatch in specialized offerings for the organization’s hiring volume and needs.

The agility of the low-code solution played a pivotal role in the project’s success, enabling rapid prototyping, immediate feedback loops with HR, and the elimination of a separate wireframing phase.

In the second phase, the project was expanded with a custom front end while keeping the low-code solution as a backend. This enabled the best of both worlds: a tailor-made front-facing hiring portal with the specific capabilities required by HR that could easily be expanded and refined.

Tailor made solution

Tailor-made solution

Scalable solution

Scalable solution

Productdock low code

Low code

Productdock fast integration

Fast iteration

Pain points.

The main driving factors behind this project were as follows:


  • High subscription cost for the existing solution compared to the needs of the organization.
  • The inclusion of additional features, such as different hiring pipelines, would not only meet our needs but also potentially escalate our costs as they are part of a higher subscription tier.
  • The existing solution required the HR team to adjust to its way of working rather than the tool adjusting to the needs of the HR team.

Phase I: Low-code applicant tracking solution and hiring portal.

The team.

The project was driven by the HR team and one low-code specialist. The HR team outlined the feature requirements, which the low-code specialist then scaffolded, followed by a review and adjustments by the HR team.


The low-code specialist handled most of the complexity, while the HR team implemented the simpler requirements directly. The development process was very agile, as the changes could be seen and tested in real-time.


The development of the new system took several days, with some additional time for handling unexpected edge cases and a few weeks for testing and transitioning from the old system.

Transition strategy.

The team opted for a phased transition, keeping the old system active until they were confident in the new solution. This cautious approach allowed for a smooth transition, and the decision to prioritize essential data transfer over extensive historical data mitigated potential complications.

Tech stack.

The new system was developed using Coda and its plugin system to address specific edge cases efficiently.


The project faced several challenges during its implementation phase.

Data migration

The existing system was not built to have an easy off-boarding experience, and backups and exports contained partial data. Because of the nature of the data, most of it quickly became outdated, so the team decided to simplify the migration by focusing on transferring only the essential data, which in their case was the blacklist and the list of candidates that opted out of being contacted in the future. The remainder of the data was backed up in an online drive where the HR team could search for it.

Data privacy

The selected low-code tool blurs the lines between the backend and the front end by operating within a document model. All information is downloaded to the user’s computer and hidden when not in use. However, this setup raises concerns as private data could potentially be accessed using browser developer tools.


To prevent this problem, the application was divided into two “documents”: one serving as the private backend and the other as the public front end. By using the “cross-doc” system, only public information was transferred from the backend to the front-end document, effectively preventing any unauthorized disclosure of private data.

Image hosting

Hosting images needed for open positions should have been a simple matter as the low-code tool supports it out of the box. Yet, during the project implementation phase, cross-doc sharing (essential for data privacy) failed to function properly with embedded images.


As a workaround, the images remained hosted in the backend document but were linked via URL rather than being inserted by dragging and dropping into the ad text. Considering how often new positions are created, the team decided that this extra step is a simpler solution than using a 3rd party hosting service, which would increase complexity and cost.

CV parsing

As Coda currently can’t extract data from PDFs, a lot of important data was “trapped” in the CVs. The HR team aimed for a more efficient application process without burdening candidates with manual data entry in their CVs.


This challenge was resolved through a custom-built plugin that enabled the team to build useful automations such as candidate categorization and application anonymization using the low-code tool’s built-in AI (powered by OpenAI).

Hiring portal UI

While the original design could be replicated, the low-code tool caused some visual artifacts (such as unwanted outlines or indicators). This issue, in combination with the limited customization for future designs, was one of the reasons why, in phase II, the team decided to implement the front-facing hiring portal as part of ProductDock’s website.

Phase II: Custom front-end.

The team

In this phase, the team was expanded to include marketing and a front-end developer. Marketing provided the visual direction and requirements for the redesigned hiring portal, which would fit better with ProductDock’s website. The front-end developer then implemented the portal. The low-code specialist made sure that the necessary data was available to the front-end without leaking any private data.

Transition strategy

For seamless operation of the hiring portal and applicant tracking system, the low-code solution was expanded so it could function with its own front end and simultaneously provide data to a separate front end. Once the new front end was completed, the low-code front end was shut down, and requests were redirected to the new one.

Tech stack

We implemented the new front end with WordPress.


Data transformation

Due to the redesigned layout, the updated front end required a change in data format. As a consequence, the HR team had to input job openings twice—once in the previous format and once in the new format—to ensure accurate display across both interfaces.


Considering the number of open positions and the fact that this only had to be done during the transition period of a few weeks while both front-ends were active, the team decided it was better to do this step manually rather than invest extra time to automate it.

Brittle URL parameters

While in the testing phase, it came to light that an applicant’s submission could become disconnected from an open position if the position name was altered while the applicant was completing the submission form. This issue occurred due to the low-code tool’s requirement for the submission URL to include the complete position name for automatic linkage to an open position.


To tackle the matter, a new immutable position ID attribute was integrated into the URL instead. By utilizing the low-code tool’s automation system, the submission and open position were connected following the form submission. Consequently, the HR team could modify open positions without concerns about delayed candidate responses due to misplaced submissions.


The project achieved several major milestones, including:


  • Phase I
    • Successful data migration
    • Parallel functioning of old and new systems
    • Automated email response system
    • Full transition to the new system
    • CV data extraction
    • AI CV data parsing
  • Phase II
    • Parallel functioning of low code and WordPress front-ends
    • Full transition to WordPress front-end


With the completion of this project, ProductDock was able to significantly reduce expenses for its application tracking and hiring portal solutions. The HR department now has a tailor-made system that behaves according to its needs and that it can modify itself. With phase II, marketing was freed to customize the front-facing part of the system even further to better fit the brand style guide.

Success criteria

The project’s success was measured through the following metrics:


  • The speed at which the new system could be ready and deployed
    • The active development of phases I and II was measured in days, with most of the time (weeks) being spent on the data transition and letting both systems run in parallel to ensure no interruptions in service.
  • Being able to completely switch to the new system and shut down the old one.
    • The old system, and phase I front-end were shut down.
  • Maintenance cost of the new system
    • $2.268 vs. $360 per year, an 84% reduction in cost. The $360 subscription to the low-code tool can also support multiple projects like this, so the savings stack up.
  • Being able to further grow and customize the new system
    • At the time of writing this case study, the team is still tweaking the system to suit their needs better.

Based on these criteria and results the project was deemed a success and a similar approach will be used in the future for other tooling.

Lessons learned

The team learned several valuable lessons from this project that they can apply to future projects. These include:


  • Low-code tools have limitations, but they can significantly speed up development and allow non-developers to change the system to fit their needs better. So, selecting ones that can be extended or work in tandem with other tools is important.
  • While the bar for low code is lower than for standard development, expert knowledge and help were still required at certain points.
  • Testing both systems in parallel is important, as this allows for catching many edge cases while not affecting the end-user experience.
  • When choosing a solution, it is important to consider how difficult it is to get your data back out. With the original system, migrating was a long manual process, and with the low-code solution, changing front-ends was a quick and straightforward process.
  • Low code simplifies maintenance as the system can be changed with a few clicks without having to know how to pull dependencies, compile, and deploy the whole application, which means that the end users can maintain the system as they use it.


The project was a success, and with the iterative and incremental approach, the team was able to explore as they went. The low-code solution allowed the whole team to be involved and enabled the first version to be deployed quickly without having to worry about hosting or who would maintain it in the future. The solution is flexible enough that it can grow and evolve with ProductDock’s needs while having a much smaller maintenance cost than the original.