Perfect Match, de-risking a matching promise built on imperfect data

A promise above its data

Perfect Match promises the merchant that describing their project will bring the right agencies, instead of searching alone through a list. Behind the promise, a legacy: agency profiles from a migration off the previous partner tool, services mapped automatically, empty fields. The product explorations that came before converged on the same observation: the trust deficit exists on both sides. The merchant wants proof at the moment of choosing; the agency shows up on projects outside its caliber, based on a profile it never built. This deficit is not fixed with one more filter. It is fixed by deciding what the product can promise with the data it actually has.

Pick up, prioritize, name the disagreement

The discovery had been stopped midway six months earlier. Picking it up started with a reframe. The initial reading made the merchant journey the subject: a brief, a results page, an algorithm. Not enough: without reliable agency data, that journey promises a match it cannot keep. The cycle was therefore framed on two inseparable, prioritized use cases: the merchant journey, de-risked first because it carries the promise, and the agency data, instrumented because it alone can keep it. Two agency populations were distinguished from that framing: the historical agency, whose migrated profile must be reclaimed before any matching, and the new agency, which builds its own from scratch.

That framing surfaced a real disagreement: was the migrated data reliable? One reading said yes, the profiles are largely filled in. The other said no, filled in does not mean validated, and matching on unconfirmed declarative data amounts to matching on noise. Rather than settling it on gut feeling, the divergence was logged as such in the project’s decision log, with a ruling on evidence by the person with access to the data. A named disagreement is worth more than a soft consensus: in six months, the team will know why the rule was set, not just which one.

The audit before the screens

The starting intuition held that good matching required new fields: project size handled, budget, availability. Asking the agencies to fill them in would be enough. That hypothesis deserved verification before drawing anything. Every available or considered signal was therefore reviewed and classified into three families: hard filters that exclude from the pool, relevance criteria that rank, tie-breakers that separate good candidates. And for each one, four questions: does the data exist, where does it come from, is it proven or declarative, what happens when it is missing.

The decision that overturned the plan

The result contradicted the plan. The fields assumed at the start were the most fragile of the matrix: declarative, unverifiable, and availability goes stale within weeks. Conversely, already proven signals were sitting idle in the existing product: the directory ranking, the expertise level granted by the program, the verified certifications.

The dilemma was set. First option: wait for the new data, ask the agencies to fill in the missing fields, and launch a rich matching on declarative data whose reliability would remain unverifiable. Second option: launch leaner, only on proven data, accepting a coarser matching where every rule can be defended. The reasoning came down to one question: what will the merchant meet at launch? With a stock of incomplete profiles, a data-hungry matching excludes agencies over a migration they never chose, and empties the results pages.

The decision: the first version runs exclusively on existing proven data, and declarative fields only come later, as refinement. A default rule completes the setup: missing data gets a neutral score and never excludes, outside hard filters. Direct consequences: the launch no longer depends on a still hypothetical collection, reclaiming the migrated profile becomes the starting point of the agency journey, and the edge cases become screens to design first.

Screens proven like the data

The same logic was applied to the design. A mockup would have shown the journey where everything goes well: three great agencies, complete profiles, an obvious match. The reality of launch is incomplete data, near-empty areas, briefs with no match. Both journeys were therefore built as a playable playground in the product repository, in Vue with PUIK, PrestaShop’s open source design system. Claude Code produced the screens within a frame defined upfront; design direction, the decisions and the review stayed human. When a component was missing from the design system, it became a candidate proposed to the system rather than a local divergence: you do not consume a design system, you feed it.

The results page was designed from the edge cases. No agency matches the brief: the screen says so, offers to widen the search and points to the full list. The shortlist is incomplete: it shows what exists, states the count, inflates nothing. In a deck of mockups, these states are the frames no one opens. In a playground, they are situations the review stumbles on, as a merchant would. The product review changed in nature: the team no longer comments on an intention, it experiences a behavior.

What the work already proves

Perfect Match is not presented here as a feature in production. It builds on the foundation described in Expert Portal: replacing a tool with a squad of three. The proof of the work is elsewhere: the previous directory could display profiles, the new portal can qualify a merchant need, turn it into usable data and prepare its handoff to the selected agencies.

What is secured comes down to three points: a relevance model where every rule traces back to a fact, a future launch calibrated on the data the product actually owns, and a playground review practice that already extends beyond this project to become a team habit. The question that will matter before production is not whether the screens were good: it is whether the neutral score rule is enough to protect trust while the stock of profiles becomes reliable.

The mandate ended in August 2026. The project was handed over with its instruments: the replayable playground, the decision log, the success criteria in place. A design that would not survive this handover would not have deserved the word.