SYSTEM_WORKFLOW

Execution Protocol

Precision-engineered workflow designed for rapid deployment and maximum scalability.

Discovery

A scoping call, then a paid discovery ending in an architecture document you own.

Design

Interface and data model designed together, including the empty and failed states.

Development

Weekly increments, each ending in a working demo on a real environment.

Testing

Automated where it pays. Accessibility and performance checked by hand.

Launch

Deployed through the same pipeline, monitored, and handed over in writing.

Most of what goes wrong on a software project goes wrong before anyone writes code, and it usually goes wrong quietly. The scope was never written down. The architecture was decided by whoever started first. Nobody agreed what "done" meant. The five stages below exist to make those decisions explicit and to put them in writing while they are still cheap to change.

The work is deliberately front-loaded. A scoping call and a paid discovery come before any build commitment, and both are designed to be survivable if the answer turns out to be no — you keep the architecture document either way. What we need from you is access to the people who actually know the domain, and a decision-maker who can answer questions inside a week. Projects stall on that far more often than on engineering.

The five stages

Most projects combine several of our services, but the shape of the engagement is the same regardless of which one you start from.

Discovery

A technical scoping call, then a paid discovery that ends in writing.

A scoping call establishes whether the problem is real, whether software is the right answer, and whether we are the right team for it — we will say so if we are not. If it goes ahead, a paid discovery follows: we read the existing system, talk to the people who operate it, and work out what actually has to be true for the project to succeed.

What you receive

An architecture document covering the proposed system, the constraints it has to live inside, the risks we found and what they would cost to carry. It belongs to you whether or not you continue with us.

What we need from you

Access to the domain experts and, where a system already exists, read access to it. Discovery done from a brief alone produces a document that reads well and predicts nothing.

Design

Interface and data model designed together, because they constrain each other.

Interface design and data modelling happen in the same pass. Screens are designed against the data that will really exist, including the empty, partial and failed states that get skipped in a demo and then dominate real use. Accessibility is decided here rather than retrofitted — colour, focus order, target sizes and keyboard paths are cheap now and expensive later.

What you receive

Reviewable interface designs and a schema, plus the list of states each screen has to handle.

What we need from you

One round of consolidated feedback per review, from someone empowered to settle disagreements between stakeholders.

Development

Weekly increments, each ending in something you can actually use.

Build runs in weekly increments. Each one ends with a working demo on a real environment — not a status update, and not a screenshot. Code is reviewed before it merges, and the pipeline runs the test suite, a dependency audit and a build on every change. Work is done by the senior engineers who scoped it; nothing is handed to a junior team once the contract is signed.

What you receive

A working demo every week, commit access to your own repository from day one, and a written note of what changed and what is next.

What we need from you

Someone available to look at the weekly demo. A demo nobody watches is how a project drifts for two months without anyone noticing.

Testing

Automated where it pays, manual where judgement is required.

Tests are written alongside the code, not bolted on at the end: unit tests around logic, integration tests across boundaries, and end-to-end tests on the few paths that would genuinely hurt if they broke. On top of that we test the things automation is bad at — accessibility with a keyboard and a screen reader, performance against real field data rather than a lab score, and the failure paths that only appear when a dependency is slow or down.

What you receive

A test suite you can run, the results from the accessibility and performance passes, and a written list of known limitations. We would rather hand over a documented gap than an undocumented surprise.

What we need from you

Realistic test data, or permission to generate it. Systems tested only on tidy data fail on contact with yours.

Launch

Deployed, monitored, and handed over so your team can take it on.

Deployment runs through the same pipeline that has been used all along, so release day is not the first time it is exercised. Monitoring and error reporting go live with the system rather than after it. Then the handover: a written document covering how the system is built, how to run it, what will need attention first, and where the bodies are buried.

What you receive

A running system, its infrastructure and credentials in accounts you own, and a handover document written for the engineers who will maintain it.

What we need from you

The team who will own it afterwards, in the room for handover. Handover to nobody is just a document.

The standards we build to

These are the published standards the work is engineered against. To be exact about what that claim is: it means the software we deliver is built and tested to meet them, and we can show you where. It does not mean DevFamz holds a certification, audit opinion or accreditation against any of them — we do not claim one, and you should be sceptical of suppliers who imply it without naming the auditor and the scope. Where a standard is genuinely certifiable, it is listed below as a reference framework and described as such.

Security

The baseline every system gets, before anything specific to your risk profile.

OWASP Top 10:2025: The current edition, published November 2025, is the review checklist for anything internet-facing. Its two new categories matter for how we work: supply chain failures moved into the top ten in their own right, and mishandling of exceptional conditions joined it — which is to say error paths are now treated as an attack surface, not just a robustness question.
OWASP ASVS 5.0: Roughly 350 verification requirements across 17 categories. We use it to set a verification level appropriate to the system rather than applying every control to every project, so security effort lands where the actual risk is.
NIST SP 800-63B (revision 4): Governs authentication. In practice it is why we will push back on composition rules and forced rotation, check credentials against known-breached lists, and treat phishing-resistant factors as the target for anything privileged.
ISO/IEC 27001:2022 — reference framework: Certifiable, and we are not certified. Its Annex A control areas are still the most useful checklist for deciding how access, logging, secrets and supplier risk get handled on a project, so we use it that way and say so plainly.
SBOM: SPDX and CycloneDX: A machine-readable inventory of what is in your build, produced by the pipeline. Increasingly a procurement requirement, and the only practical way to answer "are we affected?" on the day a dependency is compromised.

Accessibility

Built in during design, verified before launch, and now a legal exposure in the EU.

WCAG 2.2 Level AA: The build target. A W3C Recommendation since October 2023 and approved as ISO/IEC 40500 in 2025. AA is the level referenced by essentially every accessibility regime that names a version.
EN 301 549 and the European Accessibility Act: The EAA has been enforceable since 28 June 2025 for consumer-facing products and services in the EU. The harmonised standard behind it, EN 301 549 v3.2.1, currently incorporates WCAG 2.1 AA — building to 2.2 AA satisfies that and leaves you covered when the standard is updated to reference 2.2.
WAI-ARIA, used sparingly: ARIA is a fallback, not a first resort. Native elements carry their semantics and keyboard behaviour for free; most accessibility bugs we find are custom controls that reimplemented a button badly and then papered over it with roles.
Manual keyboard and screen-reader testing: Automated tooling catches a minority of real WCAG failures. Focus order, meaningful labels and whether a flow can actually be completed without a mouse have to be checked by a person, so they are.
Not WCAG 3.0: Worth stating because it gets sold. WCAG 3.0 is still a Working Draft — the March 2026 draft is not stable, a Candidate Recommendation is not expected before late 2027, and no regulation references it. Anyone offering WCAG 3.0 compliance today is selling you something that does not exist yet.

Performance

Measured on real users, at the threshold Google actually applies.

Core Web Vitals: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. The number that counts is the 75th percentile of real visitors, not a lab run on a fast laptop — a site can score well in Lighthouse and still fail the assessment Google applies.
INP, not FID: Interaction to Next Paint replaced First Input Delay in March 2024 and is the hardest of the three to pass. It measures the full interaction, so it exposes slow event handlers and heavy re-renders that the old metric never saw.
Field data over lab data: We instrument real user monitoring and treat it as the source of truth. Lab scores are useful for catching regressions in CI; they are not evidence that users are having a good time.
A performance budget in the pipeline: Bundle size and key metrics are asserted on every build, so a regression fails the build rather than being discovered in a report a month later.

Data protection

What the regime means for the build. This is engineering practice, not legal advice — take the legal question to a lawyer.

GDPR and UK GDPR: Drives concrete build decisions rather than a policy page: what is collected and why, where it is stored, how long it is kept, how a deletion or export request is actually serviced, and whether the audit trail can answer a regulator.
Gulf data protection law: The UAE and Saudi Arabia both now have personal data protection regimes in force, with Saudi Arabia fully effective since September 2024 under SDAIA. For us this usually turns into a data-residency and cross-border-transfer decision that has to be made at architecture time, because it is very expensive to reverse afterwards.
US state privacy law: A growing patchwork of state-level comprehensive privacy laws. Practically this means consent and deletion have to be designed as system capabilities rather than per-jurisdiction bolt-ons.
Encryption and least privilege by default: Encrypted in transit and at rest, secrets held in a managed store rather than in environment files, and access scoped per service. Defaults, not options — retrofitting them is where budget disappears.

Engineering practice

The conventions that decide whether your team can still work on this in two years.

OpenAPI 3.2: APIs are specified, and the specification is the source of truth for clients, documentation and contract tests. The current release landed in September 2025.
Semantic Versioning and Conventional Commits: Version numbers carry meaning and the changelog is generated from history rather than remembered. It sounds like bookkeeping until you have to work out what shipped in the release that broke.
Twelve-Factor configuration: Configuration comes from the environment, not the codebase, so the same artefact is what gets promoted from staging to production. Environments that drift apart are the reason "it worked in staging" is a sentence people say.
RFC 9110 HTTP semantics: Status codes, caching and idempotency used as specified. Predictable HTTP is what lets CDNs, clients and retry logic do their jobs without bespoke handling for your API.
ISO 8601 timestamps, UTC throughout: Unglamorous and worth stating, because timezone handling is one of the most reliable sources of data corruption we get called in to fix.

What you own

You own the output at every stage, not just at the end. The repository is yours from the first commit and we work in it. Infrastructure runs in your cloud accounts under your billing, not resold through us. The architecture document from discovery is yours even if you stop there, and the handover document is written for whoever maintains the system next — whether that is your team, us, or a supplier you have not hired yet. There is no proprietary framework you have to keep paying us to touch, and no part of the delivery is withheld as leverage.

Start with the scoping call

It is free, it is technical, and it ends with a straight answer about whether this is worth doing and whether we are the right team to do it. If you would rather see evidence first, our work covers what we have shipped, and the engineering blog shows how the team reasons about these problems before you have spent anything.

Book a scoping call