← Back/ATS / Enterprise

Talentera

Talentera is white-label hiring software: every tenant gets different pipelines, different modules, different entitlements, in English, Arabic or French. The previous frontend encoded those differences in code, so every new client became a branch of the UI and every copy change became a release. Through 2026 I led the rebuild as Lead Product Design Engineer, a Nuxt 4 monorepo where the backend serves a configs API for every page and the frontend renders it: the navigation, the topbar, the page header, the actions and all copy arrive as data, already localised, so a tenant is a configuration rather than a fork.

RoleLead Product Design Engineer

Year2026

Every tenant became a fork of the frontend. Every copy change became a release.

The product was built for one tenant shape and then sold to many, so each customer's variation was hardcoded at the point it appeared. That was fast the first time and compounding every time after.

02How we thought about it

Tenant differences are data, so the frontend should render configuration, not contain it.

I audited the previous codebase as prior art rather than as a baseline. The conclusion set the architecture. A tenant should be a configuration rather than a branch, and the real design work was the contract between what the backend serves and what the page renders.

03What we changed

Made every page consume a configs API

The header, actions, data APIs and settings arrive as data, so a page renders a tenant it was never compiled against. I authored the shape as a Zod schema and the backend owns the values.

Served navigation and copy from the backend

A tenant that has not bought a module never receives it, so entitlement becomes absence rather than a disabled control. Copy arrives already localised in English, Arabic or French, and Arabic is the same screen mirrored rather than a second build.

Built the form builder and the email-template builder in-house

The company was looking at an external builder on an annual plan of 8,000 USD. I designed and built both builders myself, inside the product, so forms and emails share the same tokens, languages and permissions as every other page. It was a large step: better integration with the system, a better experience for the people authoring, and a yearly cost the company no longer carries.

Wrote the rules down and enforced them

Configuration only stays data if no page can quietly own its own. A repository check fails any page that hardcodes its configuration, and routes derive from the backend's module registry rather than being invented.

The trade-off

I ruled out building against mocks, because a missing endpoint raised early is cheaper than building against an API nobody will serve.

04What it did

The form builder and the email-template builder are shipped in-house, saving the company an 8,000 USD yearly plan. A tenant is now a configuration rather than a branch. Copy changes, renamed stages, module availability and entitlement differences are served, not shipped.

How we knewEvidence

An architecture case: evidence is the contract between design, backend and frontend.

Code review

Quantitative

Endpoints confirmed against the pinned OpenAPI snapshot before design goes further, so nothing is built against an API nobody serves.

Design judgement

Qualitative

Languages served from the backend, with Arabic mirrored.

Usability test

Mixed

The redesigned pages and the in-house builders were tested with users and the tasks passed. Participant details are not published on this page.

Shipped

Quantitative

$8,000

A year the company no longer pays for an external form builder, because I designed and built the form builder and the email-template builder myself. The figure is the plan price I was given; it is not a measured saving.

DecisionsAnd why

What we saw, what we knew, what we chose, and what we gave up.

A tenant is a configuration, not a fork

What we saw: Shipping a client meant editing the frontend: pipelines, entitlements and every string lived in code.
Evidence: Code review· QuantitativeDifferences were hardcoded where they appeared, which is fast once and compounding every time after.
So we: The backend serves a configs API for every page and the frontend renders it, with navigation and copy arriving as data.
Not: A branch of the UI per customer.
What happened: A renamed stage or a translation fix no longer waits for a release.

User testingWhat was and was not tested

Usability study: the redesigned pages, the form builder and the email-template builder were tested with users and the tasks passed. A new tenant also ships as configuration. Participant details are not published on this page, and no adoption figures are claimed.

My role

Lead Product Design Engineer

What I personally owned on this project.

01Own the frontend architecture: a Nuxt monorepo of layers (platform, tenant, ui) under four applications, employer ATS, job-seeker, the white-label career site, and the internal management portal

02Designed the config-driven page model and authored the page-config schema the backend serves

03Set the contract-first rule with the backend: routes derive from the module registry, DTOs generate from pinned OpenAPI snapshots, a missing endpoint is a blocker rather than a mock

04Designed and built the employer admin surfaces, users and access control, roles, divisions and hierarchy, org chart and analytics, content labels, form fields management

05Wrote the repository's constitution: the feature flow, the non-negotiable rules, the definition of done, and the checks that enforce them

06Run the design-to-code pipeline end to end: design baselines, handoff index, conversion rules, and visual verification against the baseline before a surface is called done

Made with

Nuxt 4 + Vue 3TypeScript strictZod contractsPrimeVue (wrapped)Tailwind on semantic tokensVueformVitest · MSW · Playwrightpnpm monorepo

Next Project