MakeDeal turned one recruiter's playbook into a system an entire agency could run on.
An admin platform that ran the sourcing operation, a browser extension that brought it into LinkedIn, and a native keyboard for everywhere else.
1
Context Model:B2B recruiting software — built as an internal tool first, designed to become a sellable productMarket:Staffing/recruiting agencies sourcing technical talent for US clients from UkraineTeam:Led a 2-person design team, working alongside FreySoft's Head of Recruitment, a BA, and the founderKey objective:Turn a handful of skilled recruiters' tacit knowledge into a shared, measurable system — first for FreySoft, then for other agenciesMy role: Lead Product Designer, Mar 2021 – Jul 2023, built and led a 2-person design teamOne client, then a product. FreySoft started as a freelance staffing operation — I was already the founder's design partner on earlier projects, doing design while he handled development. When he began selling other developers the same way, FreySoft grew into an agency. About a month later he came back with a different kind of ask: he wanted FreySoft to become a product company, not just a service one. FreySoft's own recruiting team became the product's first client — fix the internal hiring pipeline first, then sell the result to other agencies.
2
Team The wider team Day to day, I worked alongside FreySoft's founder, its Head of Recruitment, and a BA — plus the design team I built and led myself. Building a two-person design team I joined MakeDeal as its first product designer, working solo through the earliest phase before scope grew enough to justify a team. Two different profiles were missing at that point, not just "more headcount": someone who could continue the patterns I'd already established, and a researcher who could dig into open questions and come back with a usable summary rather than raw notes. I hired for both roles: a junior researcher, and Oleksa, a mid-level designer with strong Figma craft. The research hire didn't work out — the gap between what read well in an interview and what held up on ambiguous, fast-moving research turned out to be wider than I'd screened for. It changed how I hired after that: less weight on portfolio polish, more on giving candidates a live, ambiguous problem during the interview itself and watching how they worked it. Oleksa became a genuine critique partner rather than an executor. He pushed back hard on decisions he disagreed with, and where his pushback held up, I changed course — several early calls in the product were revised because of it. Review became a two-way loop, not top-down direction. Final call stayed mine, but it was earned more than assumed.
3
Challenge The real gap wasn't a missing feature — it was that outreach quality lived entirely in a few people's heads. Skilled recruiters had templates and patterns that worked; newer recruiters didn't, and there was no consistent way to close that gap or measure whether anyone was actually improving. The market made this urgent, not just inconvenient. Hiring at the time was candidate-driven, especially for narrow or in-demand profiles — a Java developer with the right background could afford to be selective. A slow or generic response meant a strong candidate simply moved on to a competing agency's opening, and every week a role stayed unfilled was a week the client wasn't paying. Recruiter efficiency wasn't an abstract quality metric — it was tied directly to how fast the agency could staff a role and start earning from it. I ran into a smaller version of the same problem personally, outside the project: as a designer active on LinkedIn, I was regularly flooded with connection requests from recruiters clearly copy-pasting the same pitch to hundreds of people. That experience directly shaped how MakeDeal came to measure recruiter efficiency later on.
4
Discovery Finding out what "efficient" actually meant The founder's ask was blunt: measure recruiter efficiency. That's not a specification, it's a wish — "efficient" could mean speed, volume, response quality, or something else entirely, and building against the wrong one would just produce a system that measured convincingly for the wrong thing. Instead of guessing, I ran a structured round of questions with FreySoft's Head of Recruitment — a direct working session, not a survey — to find out what actually separated a recruiter who was closing candidates fast from one who was just generating activity. That session surfaced the four inputs that became the formula below, and, more specifically, which one of them was hardest to fake. That distinction is what set the weighting, not an assumption I brought in on my own.
5
Decision The product has three layers, in the order a recruiter actually touches them day to day.
The sub-sections below follow that same order: the admin platform's decisions first, then the extension, then the keyboard.An efficiency score that resists gaming That interview (Section 4) produced a weighted formula: Score = 0.15·V + 0.25·M + 0.35·C + 0.25·L
V = profile views · M = messages sent · C = approved connections · L = letters/CVs sentEach recruiter's target isn't fixed — Vtarget = P75 of comparable recruiters' volume over the last 4–8 periods, a rolling percentile rather than a static number, so one unusually busy or slow stretch couldn't distort what "on target" meant. The weight on C is deliberate, not accidental. It counts only approved connections, not requests sent. A connection request is free and spammable — the exact behavior flooding my own LinkedIn inbox at the time. An approved connection means the candidate confirmed the outreach was worth responding to. It's the hardest action in the funnel to fake, so it carries the most weight in the score. The leaderboard also splits into a company-wide ranking and a per-project ranking, so recruiters could be measured within comparable workloads, not only against the whole team at once. MakeDeal leaderboard, All members view — Views, Messages, Connects, Letters and Score columns.V1 didn't hold up under real usage. Three gaps surfaced fast: some views were coming from repeated visits within external test groups, so V had to be limited to unique views only. A few recruiters started winning on raw volume of messages and letters rather than quality, so both got capped — activity past 120% of target stopped adding to the score. And a single shared target turned out to be unfair by design: sourcing a junior or mid-level candidate is a fundamentally faster search than an exotic senior or lead, so recruiters working the harder searches were being penalized by a target built for the easier ones. V2 moved to cohort-specific targets instead of one target for everyone. Making the admin platform mobile-first, not just responsive Two separate reasons drove this. The founder needed the admin platform to be credibly "mobile-ready" to sell it to other agencies — a real buyer expectation at the time. Separately, the recruiting team worked Kyiv hours sourcing candidates for a US market; being able to check the leaderboard or pull a template outside a desk session partly closed that time-zone gap. That meant restructuring information architecture per breakpoint, not just resizing: the desktop sidebar collapsed into a full-screen menu overlay on mobile, and filters and forms that lived inline on desktop moved into full-screen views. The leaderboard on mobile — one of the three surfaces that actually saw regular field use after launch.
Fast analytics checks on mobile — the second of the three surfaces that saw regular use.
Quick template edits on mobile — the third. The full editor shipped with its complete desktop feature set (tags, sharing, move, delete), not a stripped-down version.Usage data told a narrower story than the coverage implied.
After launch, mobile usage concentrated on exactly these three surfaces. The rest of the adaptive coverage saw little real use: the sales requirement for "mobile-ready" had pulled more surface area into full responsive treatment than day-to-day field use ever needed. One shared pool of templates, two ways in This is the feature that closes the loop back to the original problem — a shared library only works if the knowledge sitting in one recruiter's head actually reaches the others. Templates split into three tiers inside My Templates: Personal (a recruiter's own drafts, kept out of team statistics entirely — visibility into your work, not surveillance of it), Owned (templates a recruiter actively uses, tracked so its effectiveness against others could be compared), and Shared — the action a recruiter takes to make their best-performing template available to everyone else. Library is not a separate system from Shared — it's where everything marked Shared ends up.
Sharing a template is the author's action; Library is the company-wide, browsable view of that same pool, organized into folders with a popularity counter ("added by N users"). Shared = the act of contributing; Library = discovering what's already there. One pool, two entry points — not two competing systems. A Library folder, tooltip showing "added by 2 users" — the popularity counter that makes Library a discovery surface, not just storage.Even drafting a new template leaned on AI — labelled honestly as AI-generated, not hidden. The same "AI before the current wave" thread as the keyboard's automatic name detection. AI Help modal in the template editor — Formality/Domain/Prompt → Generate text, labelled "by AI (chatGPT)".Copying a shared template created an independent copy, not a live link back to the original — the backend already tracked that lineage, but surfacing it in the product (so an author could see who'd adopted their template) was scoped for V2 and hadn't shipped by the time I left the project.
A CV pipeline with four ways in
Four separate channels fed candidates into the same pipeline: bulk upload directly in the admin platform, a per-vacancy branded upload link a candidate could fill in themselves, a live sync to an external ATS, and Sidetalker — a direct upload built into the browser extension (covered below). However a candidate arrived, they ended up in the same place, not four disconnected lists. A configured, ongoing sync to Greenhouse — not a one-off export.The browser extension, not the admin platform, as the primary surface Recruiters spent most of their working day in the browser, on LinkedIn itself — that's where sourcing, messaging and tracking naturally happened. Routing every action through a separate admin platform would have meant constant tab-switching away from the actual work. The extension lives directly on the LinkedIn page instead: a floating Project Tracker pill, a context menu, and the mechanisms that turn the scoring formula above into something visible in the moment, not a backend number checked later. Why the tracker is visible, not silent.
A single recruiter routinely worked several searches in parallel — for example, sourcing 2 senior frontend and 2 middle backend developers for one project, while another project needed 1 backend, 1 frontend and 2 fullstack. Without a visible indicator of which project a conversation was currently tracked against, attribution errors were easy: a message sent while the tracker pointed at the wrong project silently miscounted toward the wrong search. The pill let a recruiter see and confirm the active project at a glance, pause tracking, or switch it — including reassigning a candidate to a different project if they didn't fit the one they were originally sourced for. The tracker pill — always visible on the LinkedIn page, showing which project the current conversation counts toward.That same switching mechanism produces a direct, trackable event: Switching templates across projects silently re-points the tracker — keeping every V/M/C/L event attributed to the right search instead of left dangling on whatever project happened to be active.The extension also surfaces the concrete event behind the M term in the scoring formula: The Message Informer fires when the tracker detects an outreach message sent on LinkedIn — the M-component of the formula, made visible as an actual event rather than a spreadsheet row.Two supporting features, each solving a specific failure mode.
A reminder tool, synced to Google Calendar, existed because a less experienced recruiter could lose track of when a candidate needed a follow-up and miss the window entirely — the same experience gap the whole product was built to close. Sidetalker, a second CV-intake path launched from inside the extension, existed because the alternative — going into the admin platform to upload a CV — was a long enough detour that recruiters sometimes just... didn't, and the CV never entered the pipeline. A CV-intake path that didn't require leaving LinkedIn — one of four channels into the pipeline.Postscript — a scope cut, not a V1 failure. The extension shipped Chrome-only. The install modal offered "Coming soon" for Safari, Opera, Firefox and Edge; it never reached full cross-browser parity. A native keyboard for everywhere the browser extension couldn't reach The extension covered LinkedIn in the browser — the majority of a recruiter's working day. But candidates didn't only respond there, and recruiters weren't always at their laptop when a reply came in. Between the LinkedIn mobile app, Djinni, DOU, and direct messengers, each had its own restrictions on overlays and add-ons — nothing the extension's approach could reach. A custom keyboard was the one thing that worked everywhere a recruiter was typing, on any device, regardless of app. That mattered because of the market context from Section 3: candidates in narrow or senior profiles could afford to be selective, and a slow reply from a laptop-only workflow meant losing them to a competitor who answered from their phone first.
The keyboard plugs into the apps recruiters already live in — LinkedIn, Djinni, Gmail — not just MakeDeal itself.I designed the full extension for iOS and Android, including the parts most keyboard concepts skip: the iOS Full Access permission flow required for any custom keyboard, search with history and empty/loading/no-result states, template cards, multi-language switching, variable insertion, light and dark themes, landscape orientation, and error states for lost connection or backend outages — across five device sizes. Both keyboards shipped: iOS on the App Store, Android on Google Play. Adoption was slower than expected.
iOS itself warns users that a keyboard with Full Access can, in principle, see everything they type — and recruiters read that warning and hesitated to turn it on. The permission screen alone wasn't enough; the product needed an explicit explanation that Full Access existed to track a recruiter's own project activity, not to monitor them personally. The reassurance screen added after adoption data showed hesitation — "cannot access password, credit card, search, URL or email address fields."
6
ImpactMeasured over the two months following MakeDeal's rollout, against the two months before — with a one-month training/ramp-up period excluded from the "after" window. The recruiting team's headcount was fixed across both periods, which rules out "more recruiters" as the explanation. Figures provided by FreySoft's Head of Recruitment.
+14.6%
LinkedIn connection requests
+18.7%
Candidate reply rate
−13.2%
Onboarding time Of the three, the onboarding drop ties most directly to a specific design decision — the shared template and glossary system from Section 5 gave new recruiters a working starting point instead of building outreach from scratch. The other two reflect the system working as intended as a whole, not one isolated screen. Founder feedback
"From a raw idea, he built the entire product experience — from early discovery to launch."
Recruitment feedback
"His work on MakeDeal had a tangible impact on our recruitment processes."
Learnings MakeDeal was my first project as design lead (2021–23) — where this got learned the hard way, three separate times, after each had already shipped.Ship the guardrail with the incentive, not after it.
The scoring formula, the keyboard's permission framing, and the admin platform's breakpoint scope all needed correcting once real usage exposed a gap I hadn't designed for upfront — gaming the score, permission hesitation, unused surface area. In each case, the fix was knowable in advance if I'd asked "how does this break under real usage, not ideal usage" before shipping V1, not after.
Coverage isn't validation.
A sales requirement for "mobile-ready" pulled far more surface area into full responsive treatment than day-to-day use ever needed. Usage data showed exactly three screens mattered — leaderboard, analytics, template edits — and the rest didn't. Next time I'd ship a narrow, validated mobile surface first and expand only where usage justifies it, even with a stakeholder pushing for full parity upfront.