~/oybek.dev
Book a call
work
Frontend Lead Architect· HR SaaS

alfii

Founding frontend engineer for alfii, a UAE HR SaaS that runs real payroll. I owned the front end from the first commit — set the architecture, rebuilt the React codebase, migrated Redux-Saga to RTK Query, and fixed the money handling so payroll runs in cents end to end. I also shipped the work most frontend leads never touch: DAPI bank transfers for WPS salary payments, Stripe billing, and the full CI/CD and Docker pipeline.

Deploy time
3–4 hrs → 15 min
New endpoints
−90% dev time
Backend build
Cut in half
PR previews
Instant

alfii is a modern HR platform for the UAE — payroll and WPS salary payments, time-off, shifts, onboarding, and employee data, sold as "simpler, smarter HR software for your growing business." The company raised a $2.5M pre-seed. I came in as the founding frontend engineer and stayed on as Frontend Lead Architect, which meant I owned the front end from the very first commit and a fair amount of the plumbing underneath it.

The brief

A pre-seed HR startup has one problem above all others: it has to run real payroll, correctly, before anyone trusts it. Everything else — the onboarding flow, the time-off calendar, the shift planner — is table stakes you can iterate on. Payroll you cannot get wrong. If a rounding error turns into a wrong paycheck, the product is finished.

So the brief had two halves. Build the entire front end from nothing — architecture, components, data layer, the lot — and do it on a foundation solid enough that a small team could ship payroll and bank payments without the codebase fighting back.

Abstract neon-green circuit traces converging from many scattered nodes into a single clean spine on a near-black grid
One front end, owned from the first commit

What I built

I set the architecture and built the React app A to Z. The codebase I inherited needed work, so a large part of the job was rebuilding and improving the React itself — turning a tangle into something a team could move quickly in.

The biggest structural decision was the data layer. The app was on Redux-Saga, which is powerful but heavy: every endpoint meant action types, a saga, reducers, and selectors, and the async flow was spread across files. I migrated it to RTK Query. That collapsed most of that boilerplate into a single API definition with generated hooks, caching, and invalidation for free. After the migration, wiring up a new endpoint went from a half-day of saga scaffolding to a few lines — roughly a 90% cut in the time it took to add one. I write more about why I reach for React on real products on its tech page.

The front end doesn't exist in isolation. alfii's backend is in Python, and I worked closely with that team to define API contracts up front — the request and response shapes for each feature — so the two sides could move independently instead of blocking on each other. Contract first, then both teams build to it.

The money bug

The hardest problem wasn't visual. It was money. Currency in JavaScript is a trap — 0.1 + 0.2 is famously not 0.3, and once you are summing salaries, deductions, and allowances across a workforce, floating-point drift turns into real money that doesn't reconcile. For a payroll product that is not a cosmetic bug; it is a wrong paycheck.

I moved the whole money path to integer cents end to end — amounts are stored, transported, and computed as integers, and only formatted to a decimal at the very edge, for display. No floats in the math. That one decision is what lets alfii run payroll you can trust.

Two abstract neon-green numeric streams on a near-black grid — a jagged drifting line resolving into a single exact aligned rail
Money handled in cents, exact end to end

Bank transfers and billing

Payroll in the UAE runs through WPS — the Wage Protection System — so paying salaries means moving money through banks, not just showing a number. I integrated DAPI to handle bank transfers, so salary payments go out as actual transactions rather than a report someone re-keys into a banking portal.

On the other side of the ledger is alfii's own revenue. I did the full analysis for Stripe billing and set up the subscription workflow with the backend team, so the product could charge for itself. Standing up payments end to end — money going out to employees, money coming in from customers — is the kind of work I lean on as a fractional CTO, and it sits at the core of how I build web apps.

DevOps, because someone had to

A founding frontend role at a pre-seed company is rarely just the front end. There was no deployment story, so I built one.

I set up the git branching and staging strategy, then a full CI/CD pipeline so shipping stopped being a manual chore. Before that, a deploy was a 3–4 hour exercise; after, it was about 15 minutes. I wrote a multi-stage Docker build for the Python backend with proper layer caching, which cut backend build times roughly in half. And I wired up per-PR preview links — every pull request gets its own live URL — so product owners could click into a change and review it themselves instead of waiting for a call.

Abstract neon-green pipeline of nodes branching from a single trunk into staged stages, each branch ending in a small glowing preview tile, on a near-black technical grid
Branch, stage, preview — one live URL per pull request

The result

alfii went from an early codebase to a platform that runs real payroll, pays salaries through the bank, and bills its own customers — with a front end built to be added to, not fought with.

The numbers that mattered day to day: deploys dropped from 3–4 hours to about 15 minutes, adding a new endpoint took roughly 90% less time after the RTK Query migration, backend builds were cut in half by the Docker work, and every pull request shipped with an instant preview link for the people deciding what to ship.

This is the shape of work I take on as a senior engineer embedded in a founding team — owning a surface end to end and the infrastructure under it, not just the parts in the job title. I've written about what that white-label, senior-developer model looks like in practice.

Have something like this in mind?

Start a project