The Right Fit: Matchie.ai

We weren't short on ideas to increase job opportunities, but as we assessed the competitor landscape and adjacent industries, we knew we'd have to move quickly.

Building on an established platform comes with constraints — technical debt, existing user expectations, competing priorities. We needed the freedom to move differently.

The architecture wasn't just slowing down feature delivery. It was also limiting our ability to build withAI. The productivity benefits we saw other teams getting from AI-assisted development were diminished because of the system we'd inherited.

Meanwhile, the industry was shifting. Manual job posting and traditional discovery were becoming obsolete as AI transformed expectations for speed, matching quality, and user experience.

The competitive reality:

As we looked at competitors in the market, we realised that to compete over the next few years, we would need two things:

1. The ability to move quickly by building with AI
2. The ability to build AI into the product, where it would add real value

I put together a strategic proposal for the leadership team. The idea wasn't to dictate — it was to share initial thinking and refine it collaboratively.

The Core Thesis (simplified):
The future of influencer marketing is AI-powered. If we can't make an AI-first solution work now, we won't survive the industry transformation ahead.

The Proposal:
Launch Matchie.ai as a standalone, AI-first creator connection platform to validate our future vision without the technical and organizational constraints of The Right Fit (TRF).

• No legacy code constraints
• No existing UX expectations to manage
• No revenue model conflicts
• Built with AI architecture from day one
• Rapid iteration without fear of breaking existing systems
• Clean brand positioning in new markets

The Reframe:

Traditional discovery methods (landing pages, interviews) provide signals, not certainty. They tell us what people say they'll do, not what they actually do when their credit card is involved.

With AI accelerating development, we could now build and test a real product in the time it used to take to run extensive customer interviews (we still did user interviews). Why settle for proxies when we can get actual market feedback — with real users making real purchasing decisions — in the same timeframe?

Risk Mitigation:

• TRF continues operating, protecting existing revenue
• Clear success/failure metrics within 1 month
• Minimal resource commitment (small tiger team)
• Preserves option value for multiple paths forward

After getting alignment on the strategic proposal, I documented the concrete plan.

Success Criteria

8 Sept (Build Speed Check): Can we actually build faster?

The Core Question:
Would building with AI on a new stack actually help us move faster than our current platform?

Why This Mattered:
Speed was one of the two main drivers for the Matchie.ai bet. If we couldn't validate this within one month, we'd know early that a core assumption was wrong—before investing more deeply.

Success Looked Like:

• 95% of V1 must-have features implemented in one month
• No critical functionality gaps preventing beta use
• Performance benchmarks met
• Tangible proof that AI tooling + clean architecture = velocity advantage

The Stakes:
If we hit this milestone, we'd proceed to market validation. If we didn't, we'd have learned quickly that the technical foundation wasn't delivering the speed advantage we needed—and could redirect without significant sunk cost.

30 Nov (PMF Check): Will brands actually use and pay for this?

The Core Question:
Would brands choose Matchie when presented with the value prop and would they pay for the new value we were delivering?

Why This Mattered:
This was a test of whether we could communicate the product's value and whether that value was compelling enough to change behaviour. We needed two signals:

1. Willingness to use: Would brands actually adopt this when presented with the new value prop?
2. Willingness to pay: Would they pay enough to justify building this further?

How We'd Measure It:
We tracked key funnel metrics to validate both willingness to use and willingness to pay — from initial marketing engagement through to active usage of AI-powered features.

These metrics would give us relatively fast validation that we were building something brands would use—and early signal on whether they'd pay for it.

What Winning Looks Like:

• Evidence of willingness to use (funnel metrics outperforming old stack)
• Evidence of willingness to pay for new product value
• Beta brands report higher match quality than manual process
• Measurable improvements to opportunity creation vs old stack
• Clear path to either integrate into TRF or scale independently

What Losing Looks Like:

• No paying customers after full market push
• Clear signal that AI isn't the differentiator we believed
• Valuable learning that redirects strategy—TRF continues unaffected

Alongside the build, I ran a user research effort. I engaged 15 brands representing a well-rounded look at our target users — including small brands and agencies working on behalf of brands.

The conversations followed a deliberate arc:

• Early interviews: Problem discovery — understanding the real pain points before jumping to solutions
• Subsequent interviews: Went deeper into the solutions we were building, specifically designed to address risks we were identifying during product discovery

This wasn't research for research's sake. There was a clear effort to use these conversations to prioritise and de-risk what we were building in real-time as Matchie.ai took shape.

The product experience for Matchie.ai was designed by myself and Llayd, another product designer on the team. We intentionally leaned heavily on design primitives from libraries, like Untitled UI and Tailwind. While we wanted to have an opinion on everything, we knew, especially in the early stages, spending time deciding on the finer points of the UI primitives was not going to have a meaningful impact.

But we didn't just design, we built. Using Cursor, we coded the front-end ourselves, collaborating closely with our engineering team to ensure that even our early “vibe-coded” efforts would be robust, especially from a security perspective.

A note on building in code
I cannot understate how transformative building in code alongside the engineering team has been for me and the other designers on the team.

At the very least, building prototypes in code has clear benefits over prototyping in tools like Figma. Even if all the code is thrown away, the value remains:

• The learning the designer gains in the process
• The shared language of code that strengthens handover to engineering
• The speed of iteration when you're not waiting for someone else to implement your ideas

Increasingly, this makes me feel like a “Product Builder”, not just a designer.

Matchie.ai was initially launched as a separate brand from The Right Fit. This was intentional — clean positioning, no legacy baggage, freedom to experiment.

When we saw strong signal from both user research, marketing efforts and product usage, we made the decision to rebrand to The Right Fit.

The rationale:

• We would be migrating all clients on the old stack to the new stack
• A unified brand would reduce complexity for marketing
• It signaled confidence in the new platform as the future

We resolved to keep “Matchie” as the name of the AI assistant within the product. We're currently exploring ways to further emphasise the personality of the AI system inside the product experience.

Proposal Approved (Month 0): One month to prove we could build faster with AI.

Milestone 1: Build Speed Check (Month 1)

Result: Success.

We shipped the core feature set within the one-month deadline and had beta testers actively using the platform. The technical foundation validated our first core assumption: building with AI on a clean stack was meaningfully faster than our current platform.

With this proof point established, we moved to market validation.

Milestone 2: PMF Check (Month 2)

Result: Exceeded expectations—and shifted our strategy earlier than planned.

By mid-November, before the milestone deadline, we had strong signal across multiple vectors:

• User interviews showing preference for AI-powered matching
• Marketing funnel metrics outperforming the old stack
• Sign-up and usage patterns exceeding benchmarks
• Evidence of willingness to pay from beta brands

The signal was clear enough to commit fully to the new platform. The new platform was the path forward.

This wasn't just validation—it was a strategic inflection point. Rather than continuing to run Matchie as a separate experiment, we shifted priorities to building migration requirements for the entire brand base.

The Migration (Month 4)

With the decision made to consolidate on the new platform, our focus shifted:

• Building features required to migrate all brands from the old stack
• Ensuring feature parity for core workflows
• Preparing the experience for both new brands and long-time users

Result:Migration requirements complete and shipped. We're now focused on refining the experience for both new brands and long-time users of the old platform — a topic for another case study.

Reflections: Building an AI Product for the First Time

This was the team's first time building a product with a strong AI component. There were many learnings along the way — some technical, some about how we work.

The Foundation: Hiring Matters

We made a senior engineer hire before this initiative who had experience building AI products. This was a key ingredient in executing both milestones successfully in such a short timeframe. The right expertise at the right moment made the aggressive timeline possible.

Building in Code: No Going Back

Before this project, I had experimented with AI tools to help me design and prototype. But on Matchie, both myself and the other designer on the team jumped headfirst into building the front-end in production with Cursor.

Similar to many people I've spoken to: there is no going back after.

At the very least, using AI to build prototypes will be part of my process from here on. The speed, the learning, the shared language with engineering — it fundamentally changes how design and development work together.

Restating Goals After Major Milestones

When we reached Milestone 2 and made the decision to go all-in on the new platform, I didn't realign the team on a longer-term plan soon enough.

What happened:
About 1.5 weeks after the milestone, I noticed a lack of energy in the team. When I investigated, it became clear that goals hadn't been restated — we were “busy” without clear direction.

Why it happened:
In hindsight, this made sense. The team had been sprinting toward a clear target. When we hit it, I didn't help align us on the next goal fast enough.

The lesson:
After a major milestone, immediately reset the goals. Don't assume momentum will carry through — it needs direction.

Falling Back into Comfortable Processes

After building the initial core features, we started work on two larger product initiatives. The product team — myself included — fell into familiar habits: extended discovery, refining designs in Figma, traditional handover to engineering.

The problem:
This was in contrast to what had been working: just enough documentation to align on the problem, then start building in code as soon as possible.

What it sparked:
The realization led to fruitful discussions about when different processes make sense, specifically around the design-to-engineering handover. Not every feature needs the same approach — but defaulting to the old way without intentionality was a mistake.

The lesson:
Process defaults are powerful. If you want a new way of working to stick, you have to actively protect it — especially when the work gets more complex and the old habits feel safer.

What This Means for Future Work

Building Matchie.ai proved that AI tooling isn't just a productivity boost, it's a strategic capability. It changes:

• How fast you can validate ideas
• How designers and engineers collaborate
• What's possible with a small team

But it also reinforced that tools don't replace judgment. You still need:

• Clear goals and direction after milestones
• Intentionality about process choices
• The right expertise on the team

The “Product Builder” approach only works when you're deliberate about when to move fast and when to slow down.