Redesigned, Not Ported: Rebuilding Thrive Apply Around What Recruiters Do

Thrive Apply is the job board inside Thrive: a firm publishes a branded listing, candidates apply on a public page, and recruiters review applicants and add the right ones to a search. Many of those listings exist for regulatory reasons, so the feature has to be dependable even when few applicants are a fit.

When Thrive was rebuilt, I didn't move the old version across screen for screen. I combined recruiter interviews across roles and firms with usage data, and redesigned the flow around what recruiters actually do: draft and preview before anything goes public, keep applicants out of the main database until someone chooses them, and protect their privacy throughout. I led four decisions that shaped it and stayed in the build through release in September 2026.

I talked with associates, recruiters, partners, and principals who use Thrive, and with recruiters at other firms who manage their own listings, starting while the prototypes were still rough. We also pulled usage data on listings, applications, and how many applicants were ever added to a search.

Migration timelines pushed toward re-skinning the old front end. I argued for a net-new design: research showed that reviewing applicants is its own workflow and needed its own environment. We were cost-conscious, but a dated experience could cost us customers in the move. After weighing every user need, and with engineering moving faster on an AI-assisted development lifecycle, we built it net-new.

Research also showed what to fix first. In the earlier version, turning the feature on published a listing immediately, and draft, public, and link-only were tangled into one setting, which confused clients. In a regulated setting, an incorrect listing can cause legal problems, so I untangled drafting, publishing, and visibility into distinct settings, each telling the recruiter what they're doing and where they are in the process.

An early direction put applicant review in a side panel, which would have repeated a legacy pain point: opening every application in a new tab. I made the case for a dedicated flow, so recruiters review and process applications on one screen, in context, and move quickly through each one's actions.

The side panel still gives a quick preview without leaving the list. It mirrors the data schema of the person record side panel, so applicant details map cleanly onto a person record and recruiters read both the same way. It also shows the application ID and applied status as proof of receipt, which used to live only in a data export.

Thrive is moving from a system of record to a system of intelligence. Three calls here follow that idea.

• Protecting applicants. Applicants never see "you already applied," so the form can't be used to probe who is in a firm's database.
• Consent that carries over. Applicants agree to a privacy policy and notifications when they apply, and nothing recorded it. Consent is now captured on the application and carries into the person record, with its timestamp, so nobody re-enters it by hand, and applicants get an email with a way to revoke it at any time. Together, these closed the GDPR gaps I raised, in a follow-up that shipped in early October.
• Resolving unique identifiers. Email and LinkedIn URL are unique identifiers in the database. When an applicant matches one profile by email and another by LinkedIn, an alert asks the recruiter to resolve it instead of merging silently, since they might be different people.

Separate workflows stay separate. Applicants not added to a project stay off the main project board. In research, reviewing applicants and running a search were clearly two different workflows. Combining them would have confused both and added heavy engineering.

Built on what users already know. Listing management went in the project's menu. The new project navigation wasn't active yet, so I placed it where project managers already go, using the cognitive structures they'd already built, with a plan to move it when the new navigation lands.

A delighter, designed ahead. I added a live preview, the listing beside the form that controls it, based on one I'd designed for admin report branding. Leadership was concerned about scope, so we held it out to migrate quickly, and I made sure the designs were complete for whenever dev was ready. To our surprise, with AI-assisted velocity, engineering shipped it at the same time.

That changed how we scoped. Work we once would have split into two projects could ship as one, ticketed separately for clarity, and we learned we could try things scope had ruled out before, even while rebuilding a complex, highly regulated app.

Thrive Apply was the first large, complex project we handed off with code-based tools alongside Figma. After this, we moved almost entirely to code-based handoff, with a few flat Figma screens for pieces like components.

I guided AI closely from the first prompt and asked for several options, never one. Working the flow out in a prototype first saved about a week of Figma prototyping. Then I pushed back on what came out:

• It over-scopes and repeats itself. It adds parts of features nobody asked for, and the same element can show up two or three times on one page. It cares more about every item in the acceptance criteria than about how they work together, so I almost always cut it down.
• It fakes what already works. Even with the real logic available, it mocked behavior that only needed data. I sent it back to the real thing.
• It rebuilds instead of reusing. I made it use our tokens and components and compare itself to similar features.
• A different site gets different rules. The public applicant portal is separate from the app, so I started from the AI's version and edited it heavily rather than rebuild it in our component library. It shipped faster and is easier to maintain.

Some checkpoints don't move. I never use synthetic users. I use AI to synthesize research data, but I challenge its assumptions and push it deeper, or it stays surface level. Prototype code is a head start for dev, not production code. And every correction goes into my instruction file, so the tool learns it once.

I'm not done at handoff. I watched what landed in the dev environment as pull requests merged, joined standups, and answered dev and QA questions, adjusting designs when something couldn't be built as drawn. Thrive Apply's own address, separate from the main app and carrying the client's branding, was settled with DevOps and legal as we went.

I check in with dev and QA about what would make handoff more productive, and keep adjusting how I communicate what they need. My prototype code isn't for production, but connected to the tokens and components in our front-end component library, it gives them a real starting point.

Thrive Apply went live on September 23, 2026, and the GDPR follow-up shipped in early October. Before release it was shown at the company showcase and a company-wide meeting, where people were excited about showing it to clients.

It was also where I led the team's exploration of handing off with prototypes. I shared what I learned working live with dev and QA with the wider PM and design team, and they adopted it: a shared prototype setup followed, and PMs began starting with a basic prototype.

By the time Thrive Apply shipped, AI-assisted development had roughly doubled our dev velocity, and it has since roughly tripled. That has let me be more expansive in design scope, working in delighters and flow updates that migration had never left room for.

I'd put more time into the applicant portal. It's a well-known pattern, and under the time crunch the AI's version got about three-quarters of the way there, so I cleaned up its flow, components, and repeated elements and focused on the much heavier in-app workflow. Without the recruiter side being more elegant than the legacy product, we wouldn't have seen real change. Next time I'd give the portal the same polish.

The rest I wouldn't change. It was a time-crunched migration, we pushed hard for what we wanted, and it worked.