Designing a Weighted Matching Engine: Lessons From a Football Scouting Platform

Matching is at the heart of many products: candidates to jobs, providers to customers, players to clubs. One of our own products is a multi-tenant scouting and transfer platform for football agencies and club scouting departments. It tracks players, matches them against club requirements with a weighted scoring engine, and manages the transfer pipeline from first contact to deal close. It is in active production use by agencies managing live transfer pipelines, and we have been delivering new features weekly for more than five months.

This post shares the principles we think matter most when designing a weighted matching engine, drawn from building this one.

What the platform does

• A weighted engine matches players against club requirements.
• Data syncs automatically from external scouting sources.
• AI-assisted natural-language search helps users find players, with web grounding.
• Each agency or club works in a role-based, white-label, multi-tenant workspace.
• A deal and proposal pipeline tracks each transfer from first contact to close.

It is built with Laravel, Filament, Livewire and PostgreSQL, with a React Native mobile app.

Principle 1: Separate requirements from preferences

A club requirement contains two different kinds of criteria. Some are hard constraints: a player who does not meet them is not a candidate at all. Others are preferences that make a candidate better or worse.

Mixing the two in one score produces odd results, such as a player who fails a hard requirement ranking highly because they score well on everything else. A cleaner design filters on hard requirements first, then scores the remaining candidates on weighted preferences.

Principle 2: Make the score explainable

A number on its own asks users to trust a black box. Scouts and agents will not stake a deal on a score they cannot interpret. When a match score can be broken down into the criteria that produced it, users can see why a player ranks where they do, disagree with a specific part, and adjust the weights accordingly.

Principle 3: Let users own the weights

Different clubs value different things, and the same club values different things for different positions. Weights should be part of the requirement, set by the people who understand it, rather than fixed in code. The engine's job is to apply them consistently.

Principle 4: Matching depends on data

No scoring model can compensate for missing or stale data. That is why automated data sync from external scouting sources is a core feature of the platform rather than an add-on. In a matching product, keeping the data complete and current is as important as the algorithm.

Principle 5: Search and matching solve different problems

Matching answers "who fits this requirement?". Search answers "find me the player I am thinking of", often in loose, natural language. The platform supports both: the weighted engine for requirements, and AI-assisted natural-language search with web grounding for exploratory questions. Treating them as separate tools keeps each one simple and predictable.

Principle 6: Design for tenants from the start

Each agency or club works in its own role-based, white-label workspace. In a platform like this, tenant separation is not only about data privacy. Requirements, weights, pipelines and branding all belong to a tenant. Building multi-tenancy in from the start avoids retrofitting it across every feature.

What weekly delivery teaches

Shipping features weekly to agencies using the platform for live transfers has been the most valuable input into the product. Real pipelines expose gaps no specification would have predicted, and a weekly rhythm means those gaps are closed while they still matter to the people who found them.

A checklist for designing a matching engine

• List hard requirements separately from weighted preferences.
• Filter first, then score.
• Make every score explainable by criterion.
• Let the people who own the requirement set the weights.
• Treat data completeness and freshness as core features.
• Keep search and matching as separate tools.
• Build tenant separation in from day one.

The anonymised write-up is in our work library. Continuous, weekly delivery on a live product is how our product improvement service usually runs. For another product where two-sided trust is central, see verified onboarding for a walk-in marketplace.