Frontend Engineering
We design and ship the interfaces people actually trust with their data — bilingual by default, RTL-first by conviction, and accessible from the first commit. Every pixel we draw has an audit trail back to a design decision, a research finding, or a regulatory requirement. A misaligned number is not a typo here; it is a broken promise — so we test against the same critical-path scenarios our backend ships to.
Lighthouse perf floor
FCP on 3G
Accessibility gate in CI
Languages, RTL + LTR, same codebase
Why Frontend
The frontend is a trust surface, not a paint job
The frontend is where trust becomes visible. When a user commits critical data, the only thing standing between intent and outcome is the screen they are tapping — and if that screen lies, lags, or hides what is about to happen, no amount of backend correctness will save the relationship. We treat the interface as a trust surface: every state — loading, empty, error, partial, success, dispute — has to tell the truth about what the system is doing, in the user's language, at the moment they need it. That is why our work starts with flows, not screens, and ends in observability, not sign-off. Design and engineering sit on the same keyboard.
We refuse the modern superstition that frontend is "just the UI". Our components render server-side before the first byte of JavaScript runs, so the page is useful on a 2014 phone over an EDGE connection; interactivity then hydrates progressively where it earns its weight. Accessibility is not a phase — it is the contract that lets a screen-reader user complete the same wire a sighted user does, in the same number of keystrokes. And because every label, error and confirmation has to exist in two languages and two directions, we build internationalisation into the component primitive, not bolted on at the end. The result is interfaces that load fast, read clearly, and survive a real audit — on a Tuesday morning in Cairo or a Friday night in Riyadh.
What we build
From records consoles to approval workflows, here is what leaves our keyboards and ships to production.
Web Platforms
Server-rendered applications on SvelteKit that load in under a second on 3G — because trust starts before the login. The first byte of HTML the user receives is already useful, and JavaScript hydrates progressively only where it earns its weight.
Design Systems
A component library with accessibility, internationalisation and theming built into every primitive — one source of truth across four product surfaces. A button that passes our gate also passes yours.
Critical-Flow UIs
Confirm-and-confirm flows, input validation, impact transparency and reversal paths designed for users who may never have used an enterprise app before. Every state shows what is about to happen, in the user's language, before anything commits.
Real-Time Dashboards
Live record states, approval queues and audit timelines over WebSockets, with optimistic updates and graceful degradation to polling when the socket drops. A dropped connection never shows a wrong number.
Operator Consoles
Internal admin tools used by compliance and finance teams, with audit-grade input controls, review queues and an action trail that maps every click back to an operator ID. The internal UI gets the same accessibility and i18n treatment as the public one.
Public Trust Surfaces
Marketing-shaped pages that still ship SSR, JSON-LD and accessibility — because the homepage is also a trust surface. The same engineers who build the records console build the marketing site; there is no B-team.
How we work
Our shipping loop runs daily. Here is one orbit, from keyboard to canary.
Specify with design
Engineer pairs with a product designer on a written spec: states, copy in two languages, accessibility notes, acceptance tests. No screen is built without its states and its copy merged first.
Prototype in real code
We do not ship Figma; we prototype in the actual component library, because fidelity only exists in the real runtime. A prototype that does not render server-side is not a prototype yet.
Build against tests
Visual regression, axe-core accessibility, and unit tests run on every commit; a red build blocks merge. Tests are written before the feature is "done", not after.
Review for accessibility & i18n
Reviewers specifically check RTL rendering, focus order, and copy in both locales — automated checks cannot see these yet. Every critical-path flow gets a native Arabic reviewer.
Deploy behind flags
Feature flags and progressive rollout let us ship to 1% then 10% then 100%, with an instant revert lever. We can turn a feature off without redeploying.
Observe and iterate
Real-user telemetry — Core Web Vitals, error rates, task completion — feeds back into the next spec within the same week. Shipping is the start of the work, not the end.
Definition of done
A feature is shipped only when all of this is true
Accessible
Zero axe-core violations, keyboard-complete, screen-reader verified in two locales.
Bilingual
EN and AR copy merged by native reviewers; RTL layout verified in browser, not assumed.
Observable
Telemetry, error boundaries and user-facing error states implemented and wired to dashboards.
Tested
Unit, visual-regression and flow-level tests green; edge cases (empty, error, timeout) covered explicitly.
Documented
Component API documented; design rationale captured as an ADR when the decision is not obvious.
Tools & why we use them
Boring on purpose. Each tool was chosen for its failure mode, not its demo.
SSR-first, tiny runtime, compile-time reactivity; ships less JS than any framework we benchmarked.
Catches critical-data mistakes at compile time; we treat types as lightweight correctness proofs.
Design tokens as utility classes, so accessibility and theme cannot drift from the markup.
Cross-browser end-to-end against a real browser; we trust tests that load the actual app.
Automated accessibility lint and CI gate; catches WCAG violations before a human ever has to.
Component isolation and visual regression; our design system is the app's source of truth.
RTL and LTR from the same component tree; no separate Arabic fork of the app.
Performance budget enforcement in CI; regressions do not merge.
How we interface
Where frontend meets the rest of the company
Backend
We co-design API contracts in OpenAPI first; both sides agree on shapes before either writes code. A schema change lands as a Pull Request that breaks the build if it breaks the frontend.
QA
Pairs on end-to-end scenarios; QA writes flows against our component library, not a separate Cypress fork we have to maintain in parallel.
Design
Same Slack channel; engineers and designers review each other's Pull Requests. A Figma change without an engineering reviewer does not ship.
DevOps
We own the build pipeline together; we ship the Lighthouse gate, DevOps ships the canary rollout. Neither of us can merge a regression the other can see.
Questions we get asked
Do you really ship WCAG 2.2 AA on every release?
Yes — it is a CI gate. A merge that introduces an axe-core violation fails the build, and an accessibility reviewer signs off on every critical-path flow before it reaches canary.
How do you handle Arabic without a separate app?
The same component tree renders both directions. Our Localized string type enforces both locales exist at compile time, and an RTL reviewer verifies the rendering in a real browser before merge — not in assumptions.
Why SvelteKit and not React?
We benchmarked. SvelteKit ships the smallest runtime, the cleanest SSR, and the fewest footguns for a team that writes one codebase in two languages. It is also the runtime this very page is built on.
Do designers code, or do engineers design?
Both. Specs are written jointly, prototypes live in the real component library, and Pull Requests are reviewed by whichever discipline owns the surface. The hand-off is a myth we deleted.
What is your performance budget?
First Contentful Paint under 1.2s on 3G, Lighthouse Performance ≥ 90 on every PR, and a 100kb JS budget per route — enforced by Lighthouse CI on every commit.
Our mission
Build interfaces that earn trust by telling the truth — fast, in both languages, accessible to everyone, and observable when something inevitably goes wrong. We do not make trust feel good; we make it be good, and let the feeling follow.