Tools Chosen for Their Failure Modes
Anyone can list a tech stack. What matters is why each tool is there, what happens when it breaks, and how the interface above it was designed. This page is our engineering answer — the principles, the stack, and the product design process behind every system we ship.
Engineering Principles
Six Rules That Outvote Any Opinion
These are written down, linked from every repository, and enforced by the pipeline — not by memory or goodwill.
Typed Boundaries, Honest Contracts
Every service boundary carries a typed, versioned contract — validated in CI, never “in someone’s head”. Breaking a consumer is a build failure, not a meeting.
Small Batches, Always
Trunk-based development with short-lived branches. The DORA research is unambiguous: small, frequent changes fail less and recover faster than big-bang releases.
Write It Down: RFCs & ADRs
Non-trivial changes start as a written Request for Comments; significant architecture choices end as an Architecture Decision Record with context and consequences.
No Merge Without a Human
Research on code review — from SmartBear to Google — shows disciplined review catches the majority of defects before they exist. Every change is read by an engineer accountable for it.
Automate the Boring, Audit the Automation
Anything done twice becomes a script; anything that gates a release becomes observable, tested infrastructure — including the pipeline itself.
You Build It, You Run It
Teams own their services in production — dashboards, alerts, pager. Ownership is the cheapest quality tool ever invented.
Product Design
Designed for the Worst Day, Not the Demo
Product design at FiduciaWay is an engineering discipline. Designers sit in the same pipeline as code: their work is versioned, reviewed, tested with real users and shipped behind the same gates. An interface is a contract with a human being — we treat it that way.
1 · Discover
Field research and data before pixels: interviews with real users in Arabic and English, failure-mode walkthroughs, and a written problem statement the whole team signs.
2 · Define
Flows, states and error paths defined before the happy path gets polished. Every screen is specified for empty, loading, partial, offline and failure states.
3 · Design
A living design system — tokens, components, RTL-first layouts — so accessibility and consistency are inherited, not re-argued per screen.
4 · Validate
Usability testing with target users, WCAG 2.2 AA audits with assistive technology, and performance budgets checked against real devices on real networks.
5 · Ship & Measure
Designs ship behind feature flags, and the loop closes with telemetry: task success rates, error encounters, and time-on-task feed the next discovery round.
Performance Budgets
Numbers We Refuse to Ship Above
Budgets are enforced in CI — a change that blows a budget fails the build, exactly like a failing test. These apply to every customer-facing surface we ship.
critical path, gzipped
largest contentful paint, p75 mobile
interaction to next paint
unhandled console errors on load
The Stack
Boring Where It Counts, Bold Where It Pays
A short list, deliberately. Each choice has an Architecture Decision Record explaining why it is here, and an exit strategy for the day it stops being the right answer.