The Algorithm Behind a Dating App Could Fix Your Rota

A government-backed dating app in Singapore recently made headlines for using the Gale-Shapley algorithm to match people up. It's a 70-year-old piece of maths, originally built to solve a completely different problem: matching medical graduates to hospital placements so that nobody ends up somewhere they hate when a better fit was available. The dating app bit is the interesting headline. The underlying idea is the useful bit, and it turns up far more often in business software than most people realise.

What "stable matching" actually means

The problem Gale-Shapley solves is called stable matching. You have two groups, each with preferences about who they'd like to be paired with. A stable match is one where there's no pair who would both rather be matched to each other than to who they've got. If that pair exists, the match isn't stable, because they've got an incentive to break it and pair up instead.

That sounds abstract until you swap "people on a dating app" for things you actually deal with:

• Sales reps and inbound leads, where reps have strengths and leads have needs
• Freelancers or contractors and jobs, where both sides have preferences about fit
• Staff and shifts, where people have availability and preferences and the business has coverage requirements
• Mentors and mentees, or buddies and new starters, in any structured onboarding programme
• Drivers and delivery routes, where some routes suit some drivers better than others

In every one of these, you're not just filling slots. You're trying to avoid the situation where two people would rather have swapped, because that's exactly when things start falling apart informally. Someone starts quietly trading shifts. A rep asks to be reassigned. A freelancer turns down the next job because the last one was a bad fit.

Why this is harder than it looks on a spreadsheet

Most businesses handle allocation problems like this with a spreadsheet, a rota template, or whoever's turn it is to shout loudest in the group chat. That works fine with five people and five slots. It stops working once you've got real preferences on both sides and more than a handful of options.

The reason it breaks isn't effort, it's the maths. With even 20 people and 20 slots, the number of possible pairings is astronomically large. A person doing this manually can't check whether a better, more stable arrangement exists somewhere in that space. They just find an arrangement that seems okay and move on. The result is usually "fine", but fine isn't the same as stable, and the gap between the two shows up as constant small renegotiation: swapped shifts, reassigned accounts, people quietly unhappy with what they got.

Gale-Shapley guarantees a stable outcome exists and gives you a method to find it, every time, in a predictable amount of computation. That's the actual value. Not that it's clever maths, but that it removes the guesswork and the drift that comes from doing this by hand.

Where it's worth building, and where it isn't

This isn't a tool for every rota. If you've got three staff and three shifts, a spreadsheet is still the right answer. It starts being worth building into your software when at least two of these are true:

• You're redoing the allocation regularly (weekly rotas, daily lead distribution, recurring project staffing)
• Both sides of the match have genuine preferences, not just availability
• Getting it wrong has a cost, in staff turnover, missed sales, or unhappy clients
• Someone currently spends real time each week doing this manually and still gets complaints about the result

If that's your business, the fix isn't a smarter spreadsheet template, it's a small piece of custom logic sitting behind whatever system already holds your staff, leads or jobs. It takes preferences in, runs the matching, and gives you back an allocation that's provably stable rather than just "the one Dave came up with on Monday morning".

What this actually looks like in practice

In a real build, this is rarely a standalone feature. It's usually a small matching engine bolted onto something that already exists: a scheduling tool, a CRM, an internal dashboard. The preferences come from a form, a ranked list, or data you already collect (skills, location, past performance). The matching runs on a schedule or on demand, and the output is just a normal allocation screen, no different to what staff already use. Nobody needs to know there's an algorithm behind it. They just notice the rota stops causing arguments.

The hard part isn't the algorithm itself, which is well understood and not that much code. The hard part is deciding what "preference" actually means for your business, how ties get broken, and what happens when someone's unavailable halfway through a cycle. That's the design work. It's the same kind of work that goes into any piece of business automation: figuring out the messy real-world rules before you write a line of the matching logic itself.

If you're currently paying someone to manually juggle an allocation problem every week and it still produces complaints, it's worth working out what that actually costs you in hours before deciding whether it's worth fixing properly. My manual admin cost calculator is a quick way to put a number on it.