How Code Becomes Trust
This page documents, end to end, how a change travels through FiduciaWay — from the moment an engineer writes it to the moment it runs in production, and what happens if anything goes wrong along the way. It is the same workflow behind all four platforms, and it is the honest answer to “why should anyone trust your software?”
The Development Cycle
Six Phases, No Phase Skipped
The cycle below governs every initiative — a two-week feature or a two-year platform. Phases scale in depth, never in number. Skipping one is a decision that requires a written exception, signed by an engineering director.
Discover & Frame
Product, design and engineering frame the problem together: user research, data, constraints and a written problem statement. No solution is discussed until the problem survives a review.
- Interviews and telemetry reviewed in Arabic and English
- Written problem statement with success metrics
- Failure-mode walkthrough: what could make this worse?
Design & RFC
Non-trivial changes are proposed as a Request for Comments: approaches considered, contracts touched, migration and rollback path. Architecture review for anything crossing a boundary — recorded as an ADR.
- RFC open for review at least 48 hours
- ADR written for boundary-crossing decisions
- Security review for auth, secrets or data flows
Implement on Trunk
Short-lived branches, small pull requests, continuous integration. Research behind trunk-based development — and DORA’s own capability model — links small batches to lower failure rates and faster recovery.
- Branches live hours, not weeks
- PRs kept under ~400 lines where practical
- Pre-push hooks run lint, types and fast tests locally
Review & Merge
Every change is read by at least one engineer who did not write it. The SmartBear and Google studies agree on the operating envelope: small diffs, focused sessions under an hour, and reviewers accountable for what they approve.
- No self-merge, no exceptions — including the CTO
- Review SLA: first response within 4 working hours
- Review checklist: correctness, tests, contracts, security, accessibility
Verify in the Pipeline
The pyramid runs on every push — unit, contract and integration suites — alongside static analysis, dependency and secret scanning, and accessibility checks. Coverage of critical paths is tracked; the number is honest, the trend is the metric.
- Unit + contract + integration on every push
- SAST, dependency CVE and secret scanning
- End-to-end suites against production-shaped staging
Release & Operate
Progressive delivery: staged environments, canary percentages, SLO watch and automatic rollback. Then the loop closes — telemetry and incident learnings feed the next discovery phase.
- Deploy ≠ release: feature flags decouple the two
- Automatic rollback on SLO breach at any stage
- Blameless postmortem within 72 hours for Sev-2+
The Code Update Workflow
Anatomy of a Single Change, Gate by Gate
Follow one change — a fix, a feature, a dependency bump — through the exact gates every FiduciaWay repository enforces. Median door-to-production time is 47 minutes; the record of what passed is permanent.
Commit & Pre-Push
Signed commits; local hooks block secrets, unformatted code and failing fast tests before anything leaves the laptop.
Pull Request & Human Review
Small, described, linked to its RFC or issue. An engineer who did not write it must approve — review is where 6 to 9 of every 10 defects die.
CI: Build & Test
Reproducible build, then the pyramid: thousands of unit tests in minutes, contract tests against consumer expectations, integration suites on ephemeral environments.
CI: Security & Quality Scans
Static analysis, dependency CVEs, license compliance, secret scanning, accessibility linting — mapped to NIST SSDF practice PW.7 (peer review) and PS.1 (tooling).
Artifact, SBOM & Provenance
The build emits a container image, a signed SBOM and SLSA provenance — an attestation of exactly which commit built it, on what, with which dependencies.
Staging Verification
Deployed to a production-shaped staging: smoke suites, end-to-end journeys, migration dry-runs and performance checks against the budgets.
Canary Rollout
1% of traffic, then 10%, then 100% — with error rate, latency and business-metric watch at each step. A regression is seen by dozens before it can reach millions.
Verify, or Roll Back
Post-deploy checks against SLOs; any breach pauses the rollout and rolls it back automatically. A reverted deploy is a routine event, not an emergency.
Observe & Learn
Traces, metrics and logs tell the change’s story for its whole life. Incidents become blameless postmortems; learnings become pipeline rules.
Quality Gates
What Must Be True to Move Forward
Gates are enforced by the pipeline, not by goodwill. A red gate stops the line — for everyone, at every seniority, on every platform.
1+ approving human review · CI green · no unresolved threads · contracts compatible
SBOM attached · SLSA provenance signed · image scans clean of critical CVEs
smoke + E2E suites green · migrations dry-run clean · performance budgets intact
error rate within SLO · p99 latency within budget · business metrics flat-or-better
both prior canary steps clean · rollback rehearsed · on-call briefed for the change
Delivery Metrics — DORA Four Keys
We Measure Ourselves in Public
The DORA research program defined the four keys of software delivery performance. We track them weekly across all platforms and publish the numbers to clients — because a company that asks for trust should hand over its own scoreboard.
Deployment frequency
on-demand deploys across platforms — elite band territory
Lead time for changes
commit to production, median 47 minutes
Change failure rate
of deployments cause a rollback or incident — elite is ≤ 15%
Failed deployment recovery
median time to restore service, rollback included
When Things Break
Incident Response, Rehearsed Like a Fire Drill
Reliability is not the absence of failure — it is the discipline of failing small, recovering fast and learning out loud. Every engineer carries the pager; every incident has a commander, a scribe and a written aftermath.
15-min page acknowledgment · all-hands bridge · client comms within 30 min · exec review
15-min acknowledgment · incident commander assigned · postmortem within 72 h, published
same-day triage · fix through the standard pipeline · postmortem if client-visible
next-business-day handling · batched into the weekly reliability review
- Blameless postmortems: name the system, never the engineer
- Error budgets: at 99.99% SLO we may spend 52 minutes of unreliability a year — and feature work pauses when the budget is burnt
- Game days: quarterly chaos drills inject failures into production paths, on purpose, with observers
- Public status: uptime and incident history are visible to clients, not hidden behind a login
Security in the Loop
Secure by Pipeline, Not by Promise
Our secure development practice is mapped to the NIST Secure Software Development Framework (SP 800-218) and verified against OWASP ASVS — so “we take security seriously” is a checkable claim, not a slogan.
Prepare the Organization (PO)
Secure-coding enablement, tooling and ownership defined per team — SSDF’s foundation practices, with annual secure-development training for every engineer.
Protect the Software (PS)
All source in signed, access-controlled repositories; branch protection and mandatory review make unauthorized code changes structurally impossible.
Produce Well-Secured Software (PW)
Threat modeling for new surfaces, peer review (PW.7), multi-layer static and dynamic testing, and hardening defaults — from dependency choice to container image.
Respond to Vulnerabilities (RV)
Continuous CVE scanning with SLAs: critical fixed in 48 hours, high in 7 days — and a coordinated-disclosure policy with a public hall of fame.