Case study · AI · 2025 – now
Every search set up by hand.
Now, in the app.
I built the screens that brought sourcing and assessment into ama's app: first for ama's team, then for every user. This is how they grew from a rough mockup into the way the team works.
- Role
- Senior Frontend Engineer
- Team
- 2 frontend engineers
- Timeline
- Apr 2025 – now
- Stack
- React, TypeScript, React Query, Tailwind, WXT
At a glance
Built · the screens for setting up and adjusting how ama finds and assesses talent.
But · every client's search was set up by hand, outside the app.
In the end · since April 2026, none have been.
A product on the move.
ama is an AI recruiting platform that helps companies find and hire the right people, fast. When I joined its small team in April 2025, the product already worked, with a handful of core screens for projects and talent.
My job, with one other frontend engineer, was to help it grow as customers asked for more.
Behind the curtain.
Much of what made ama work happened where users couldn't see it. They couldn't see what ama was looking for in a candidate, or how it searched. To change either, they asked ama's team, who set it up by hand, outside the app.
Every adjustment waited on a person. Users got the results, but not the controls.
Four decisions.
Backend first, then the screen.
The assessment criteria weren't a screen I could build from a design alone. They were deeply nested and each kind was shaped differently, so one careless update could overwrite the wrong thing. I learned how they worked first, then wrote the helpers that let the app find, change and copy any criterion safely.note 1
Show the data before you filter it.
Range filters on the talent list were plain sliders, so users narrowed a pool without seeing what was in it. I replaced each one with a small bar chart of how talent is spread across the range, so users see what they're about to cut before they cut it.note 2
Long jobs you can watch.
Finding and assessing talent takes time, and users used to start a job and wait with no feedback. I added progress notifications that update live and follow you around the app. Users can keep working while a search runs.
ama, inside LinkedIn.
Many recruiters live in LinkedIn. I built ama's LinkedIn extension, from architecture to store releases, and kept shaping it with customer feedback. One React and TypeScript codebase, built with WXT, ships to Chrome, Firefox and Edge, and users reply to candidates without leaving LinkedIn.note 3
“The biggest ones.”
On 30 April 2026, someone on ama's team who sets up searches for clients listed what had changed his work over the last few weeks. Among the biggest: sourcing in the app.
In January, it had been bare bones. Here's how it got there.
It wasn't even ama's.
My starting point was a rough mockup from outside the product. The first version shipped from it, bare bones.
None of ama's design.
So I rebuilt it from ama's own components, and asked the team whatever I didn't know.
Only a sketch of the data.
The mockup gave an idea of the data, not the full picture. I learned what the backend could give, and made the calls the mockup couldn't.
Nothing for the bad days.
Empty results, errors, long waits. From February to April, I built, tested and rebuilt until the team's work could happen in the app.
Shipping it was the start.
Finishing it was the job.
In users' hands.
- AI-written messages generated in the extension since June 2026
- 100,000+
The screens went to ama's team first, then to every user. Users can now see what ama looks for and how it searches, and change both themselves.
Your turn
Move the range. See what you'd cut.
A recreation of one of the first things I shipped at ama, with sample data. The bars show who's in the pool before you narrow it.
What I took with me.
The sourcing screens I built from that rough mockup are still in use today, even as the product keeps changing around them. That's the part I'm proudest of.
It's how I judge my work now. Can the next feature stand on it? In September 2026, I removed files nobody used anymore, so the next person builds on less.note 4
Back to the top ↑Also in this series
Squad · PaymentsCloser to the money, every year.Read the case study →Let's talk
Still doing it by hand? Let's build it into the product.
Send me a note. I reply within two working days.
Prefer your own inbox? Email me directly