Case study

Recruiting analytics platform

Five years as the single owner of an established Swiss recruiting platform, covering infrastructure, code, new features, customer requirements and onboarding, plus the number of smaller products built around it. 
Senior architect's hands sketching infrastructure diagrams on whiteboard during technical planning session

Five years running an established Swiss recruiting-analytics platform

Sector Recruiting analytics SaaS · Market Switzerland · Duration ~5 years · Role Product owner end to end: architecture, development, infrastructure, customer onboarding

The challenge

The platform evaluates job candidates against both hard and soft factors, and had become an established fixture of the Swiss market: 50+ enterprise customers, 18,000 active users, and a Swiss public institution running its entire hiring process through it.

A system that large enterprises and a public institution depend on for hiring decisions can't be changed casually, can't go down, and can't mishandle candidate data. It had to be online 99% of the time, and every change had to land on a live platform with customers working on it every day.

And we had to take it over quickly. The platform came to us as a large, complex codebase running on an equally complex Azure infrastructure, together with a set of smaller PHP products built around it. We had a short window to learn it, and from then on we were running it and improving it at the same time.

The core platform also ran on .NET Framework 4.7, an ageing runtime that tied it to Windows hosting and limited how it could evolve.

Laptop screen displaying database architecture and API integration diagrams with technical documentation and notes on desk

What we did

Took full ownership, fast. Within a short period we were running the whole thing: codebase, infrastructure, operations and customers. The platform's Domain-Driven Design helped. Core business logic was cleanly separated from infrastructure code and other concerns, so a codebase of this size was easier to understand, and safer to change, than it first looked.

Found what to improve, then improved it. Early in the engagement we identified where the platform could perform and scale better, where security around the system could be tightened, and where it could be easier to use for recruiters and candidates. We then worked through that list alongside day-to-day operations.

Moved the platform onto modern .NET. We migrated the whole platform from .NET Framework 4.7 to .NET 5, and then on to newer .NET versions as they came out. We maintained the AngularJS frontend throughout the engagement.

Kept it online. A 99% availability requirement means seeing problems before customers do. We put complete monitoring and tracking across the system and owned the Azure estate end to end: provisioning, networking, deployment and day-to-day operations. With no handoff between the people who write the code and the people who run it, there's no gap for a problem to fall through.

Close-up of colorful database architecture diagram being drawn on glass whiteboard with dry-erase markers

Treated data privacy and security as core work. Candidate data is personal data, and on a recruiting platform much of it is sensitive. Securing and protecting it was a large, continuous part of our work across the whole system, from infrastructure to application. We kept each customer’s data isolated from every other customer’s and controlled access by role. Data was encrypted at rest, and every transfer between the system’s services was secured, so candidate data was protected wherever it was stored or sent.

GDPR compliance was part of how the platform ran every day. When candidates withdrew their consent, we made sure their personal data was really cleaned up and anonymised across the whole system, in every service that held a copy.

Tested everything and automated delivery. Every feature we implemented was covered by unit, integration and end-to-end tests. We introduced CI/CD pipelines that continuously tested and integrated the latest changes across all four environments: staging, tech preview, demo and production.

Rebuilt the products around the platform. We took over the smaller PHP products as well, refactored them, gave them a new UI design and kept adding features. As a result, the whole product family moved forward together, not just the core.

Owned the customer side too. We worked out requirements directly with the platform's customers, translating what a recruiting team asked for into changes that fit a system already carrying years of logic. Our team also onboarded new enterprise customers, brought them live and supported them afterwards.

Stayed through a change of ownership. We carried the platform through a change of ownership and a change of contracting entity without a handover gap. 

Overhead flat-lay of software development workflow showing wireframes, design mockups, laptops, and technical documentation on white desk

Result

For five years, 18,000 active users across 50+ enterprise customers worked on a platform that stayed online, stayed secure and kept getting better, and the flagship public-institution customer stayed throughout.

By the end, the core had moved from .NET Framework 4.7 to modern .NET, every change went through automated tests and pipelines across four environments, and the surrounding products had been refactored and redesigned. One team held infrastructure, code, security and customers the whole time, and handed the platform over in a state its new owners could run.

Stack · .NET Framework 4.7 → .NET 5 and later · ASP.NET Core · AngularJS · CouchDB · PHP · Microsoft Azure · CI/CD with unit, integration and E2E test gates


Client name and reference available on request under NDA.

Need one team to own a platform that can't go down?