Why did this project start?

Compensation was hard to see from both sides, and we knew it was a gap.

• For the worker: the only place they could see their pay was the payslip. No salary range, no sense of where they sit in it, no total picture. Anything more than that meant chasing it down.

• For the client (admin): when an employee asked about their pay, the admin had to put the answer together by hand, matching an Excel sheet of salary bands against payslips to give the full picture.

What set the clock was the EU Pay Transparency Directive. Employers have to show pay ranges and how pay is decided, with national laws due by June 2026. Deel had nothing native for this, so the directive set both the deadline and how fast we had to move.

Key challenges

It looks like a simple page; the data behind it isn't

The new compensation hub reads like one clean dashboard, a few charts and a number. The real work was in the edge cases underneath:

• A worker can hold more than one role, so which salary band do you show?

• People are often paid in a currency other than the organization's, so which currency does the page speak in?

• Past pay was calculated at exchange rates on that day, but we don't store those exchange rates. So what rate was used?

• Some counties speak of compensation in monthly values and others annual, so what to display here?

A legal deadline we couldn't move

The EU directive meant every client with EU workers needed a way to show pay ranges by a set date, and Deel had nothing for this. I had to design the worker view and the admin setup behind it, and get both right, in about three weeks.

My approach:

• I used AI to turn my vision straight into clickable prototypes. The team could click through it instead of picking apart static mocks, so we caught the problems early. That's what made three weeks realistic.

• I also drew a clear line with stakeholders early: we were building a tool that they can use to disclose pay, not enforcing compliance with the new law.

The solution (V1)

Pay made visible, with the employer in control: V1 gave workers a clear view of their own pay to meet the EU transparency laws, and gave employers full control over what that view shows.

What the worker sees

One My Compensation page that pulls together what used to be scattered:

• the job profile (family group, family, track, level)

• the salary band with where they sit in it

• total cash (base, bonus, allowances) as one number with an annual or monthly view

• the average salary by gender for their role.

Designing for edge cases and adding guardrails

• Most of the work on the worker side was in the data, not the layout: pulling every figure reliably, and handling the cases where it is thin or missing.

• The average-salary-by-gender block only appears once a group is large enough that no one can be identified.

• Every block has a proper empty and error state, because on a page of sensitive pay data, "no data yet" has to look deliberate, not broken.

What the employer controls

• Turns the portal on for desired country, worker type, or employment type.

• Chooses exactly what shows, with a toggle for each block.

• Previews the worker's view before publishing.

The core decision: control, not automation.

• We expected customers to want us to do the hard part: read each country's rules, recommend what to disclose, and switch it on in one click.

• I ran customer interviews to test that, and they wanted the opposite. Because pay is sensitive, employers want to decide exactly what they show, whatever the local rules require.

• So the product is built on the employer keeping full control, which also kept us out of a brittle per-country rules engine we would have had to maintain.

Trade-offs

• One currency for V1: Deel pays people anywhere, so compensation spans currencies. I showed everything in the organization's currency for a consistent view, and scoped a worker-facing currency selector for later.

• Desktop first, native mobile later: a real mobile experience meant building natively in React Native, not shrinking the web app, which we could not do well by the deadline. Desktop shipped on time, and the native mobile version followed in V2.

V2: from an add-on feature to the whole organization

When V1 shipped on the EU deadline, the launch got a real marketing push, and the attention it drew shaped V2.

• Management saw a product worth pushing further than only the add-on customers.

• Customers who saw the worker view wanted the same picture for themselves: admins being able to see their workers' comp and managers their teams' comp.

• Companies that had never bought the Compensation Management add-on started asking for the portal too, which was the opportunity to upsell.

A second version was also the moment to improve based on user feedback.

👉 V2 had three goals: reach the whole organization, upsell the add-on, and improve features from user feedback.

Goal 1: reach the whole organization

• In V1 the portal lived inside the Compensation Management product, so only companies that had bought the add-on ever saw it.

• To reach everyone, I moved it out to its own page in HR settings, which meant reworking the navigation.

On mobile, too

The native mobile app, the one deferred in V1's desktop-first trade-off, brought the worker view to phones, so people see their pay where they already check everything else.

Challenge: A single place for compensation, not another tab

• Compensation was already shown in several places on the client side, and opening it to admins and managers would have added another.

• I pulled it into a single Role and Compensation widget, with tabs for the current view, role history, and compensation history, so there is one place to go for anything compensation-related.

Challenge: designing the manager view for different permission levels

Showing pay to managers needs strict permission management and I designed what the portal shows for 3 permission levels:

1. No comp access

2. Current pay only

3. Current + history

Goal 2: driving cross-sell revenue

• The portal runs on salary band data only the add-on provides. Everyone sees the portal with their basic compensation data, and for a company without the add-on the bands are visibly missing.

• They get a preview of the full picture, they just cannot see or build the bands, so buying the add-on is the obvious way to complete it. Real value first, not a marketing page.

• Growing add-on revenue was an organization-level priority at Deel, and the portal turned out to be a natural place to drive it.

Future: A/B testing planned for Q4 2026 to optimise these upselling surfaces

Goal 3: iterating based on customer feedback

I conducted user interviews as well as collected async feedback. Since there were numerous tiny improvements, I'm highlight only one example below.

An example: Compensation progression

• In V1, compensation progression was a bar chart, and user interviews showed it was hard to read: does the 2024 bar correspond to my salary before or after my raise in June? Is it prorated or annualised?

• So in V2, I put the date of each pay change on the x-axis and moved to a stacked area chart with base pay as the foundation, so it reads as "on this date, your pay became this."

• It also removed a modeling headache: with mid-year changes there is no single annual total to argue over, because the chart shows each change rather than a sum.

V3: I didn't stop at functional

V1 shipped the MVP. V2 built it out to the whole org. V3 is where I went further and added delight:

A promotion should feel like one: the Pay Raise envelope

• A promotion is one of the best moments in someone's working life. However, the product delivered it like any other update: a templated email and a generic notification.

• We had just built a whole portal to make pay clear, so I pushed it one step further: when you get a pay raise, it should land like a moment worth celebrating, not a default alert.

• The worker opens an envelope that reveals their new role and pay, and it can even carry the company's own branding.

How I got my delight idea greenlit in just one day using AI

• Implementing it meant convincing stakeholders to spend engineering time on something that looked like a nice-to-have.

• So instead of pitching in slides, I vibe-coded a working prototype in a day and shared a live link. People could open the envelope and feel it themselves, and that won the buy-in to build it for real.

Bonus: You can see the other concept I pitched (Polaroid) in the video

Two smaller improvements alongside

• A filter bar for currency and scale (annual, monthly, weekly or hourly), so workers can choose how they want to view their pay

• Other related Deel products can now also add widgets in the portal. E.g. performance reviews, career ladders etc.

Impact

I took a compliance-forced MVP and turned it into an org-wide growth surface with in-context cross-sell, plus a flagship delight moment.

• 3 weeks from first concept to full rollout, ahead of the EU Pay Transparency Directive deadline. Directly building the clickable prototype with real Deel components is what made that pace possible.

• The numbers aren't in yet, and here's what we're tracking.

  • Portal activation: how many companies turn it on, and how many workers open their page

  • Upsell click-through rate: the click-through rate is the first read on whether the portal works as a growth surface. If the numbers are favourable, the next step is growth experiments to optimise the upselling.