Every marketplace has the same central problem and most of them try to solve it too early. Matching supply to demand is the product; everything else is plumbing. So the temptation is to build the matching engine first, because that is the interesting part and the part that sounds like a technology company.
The roadmap I co-authored for a three-sided talent marketplace at Xynteo, where I was Chief Digital Officer, did the opposite. It planned five stages, and the matching moved from human to machine across all five.
The sequence
In the first stage, tasks were added to the platform by hand and matching ran on a manual search. People registered through a process designed to capture structured information about their background, and integrations with external assessment tools collected the unstructured part — skills, personality, motivations. Basic tooling let a human compare candidates, give feedback and talk to both sides.
In the second, the work expanded from one person per task to several people on the same task, with a shared workspace for exchanging files, signing documents and completing milestones. Matching was still manual, but now it ran against a sifted pool with a predictive model pointing preliminarily at candidates. A proof of concept for matching on hard and soft skills was built here — built, not deployed.
In the third, the algorithm did the initial matching and administrators calibrated the results by hand. This is the stage people want to skip and it is the load-bearing one.
By the fifth, matching was automatic: a client received a shortlist of five candidates for a task, and the platform had moved on to identifying gaps in people's skills and suggesting how to close them.
Why the manual stages are not a stopgap
The usual reading of a roadmap like this is that the early stages are a compromise — we would automate now if we could, so we will fake it with humans until the engineering lands. That reading gets the causality backwards.
A matching algorithm needs examples of good matches. Not applications, not profiles: outcomes, where someone was put on a task and it went well or badly, labelled by someone who knows which. A platform that automates matching on day one has no such examples, so it matches on the only things it has — keyword overlap and self-reported skills — and produces confident nonsense. Worse, it then trains on its own output.
The manual stages are how the training set gets made. Every hand-made match is a labelled example. Every administrator correction in the calibrated stage is a label on the model's error, which is more informative than a label on its success. By the time matching goes automatic, the system has been taught by people who were doing the job properly rather than by a cold start.
The staged targets in the roadmap say the same thing in numbers: thousands of people sifted and a handful of closed projects early, rising to fifteen thousand sifted and fifteen closed later. Sifted rises far faster than closed. The platform is deliberately learning about many more people than it places, which is what you want, and it means the closed projects — the ones with outcomes attached — are the scarce, valuable thing.
The parts that are not matching
Two other decisions in that roadmap have stayed with me.
Volunteer work counted. Pro-bono projects were open to everyone, and how someone performed on them fed their matching score. That solves the cold-start problem for a person the way manual matching solves it for the platform: a new entrant with no history on the system can generate one, at low stakes, in public. Most marketplaces leave newcomers to accumulate reputation by luck.
And the later stages moved into things a pure marketplace would consider out of scope — physical hubs and co-working space for the community, skills development where gaps were found, and a pilot of social-security benefits and compensation programmes for the people doing the work.
That last one is the interesting commitment. A talent marketplace optimising only for match quality drives toward the arrangement where nothing is permanent and everyone is repriced continuously. Building benefits into the roadmap is a statement that the platform intends to be a place people can work rather than a mechanism for arbitraging them. It is a product decision with a moral argument inside it, and it was made early, in the roadmap, rather than left to be retrofitted after the model worked.
What I would carry into any matching product now
Sequence the intelligence behind the evidence. Decide, at the start, which stage produces your labels and who does the labelling — and treat their corrections as the most valuable data the system generates, not as a cost to be automated away.
The instinct to build the model first is the same instinct that builds a dashboard before anyone has agreed what the numbers mean. In both cases the machinery arrives before the thing it is supposed to be reasoning about, and in both cases it produces answers immediately, which is exactly what makes it hard to notice that they are not answers to anything.