Solutions/Quality Engineering

Engineering discipline·Review to day two

Architecture reviewed,
tested and validated before production.

Design review, automated verification and lab validation ahead of national rollout — technology proven in a lab, not on citizens.

PracticeQuality Engineering

Applies toArchitecture, platform, code, operations

GatesContract · Integration · Performance · Security

Proving groundMetaminds innovation lab

Carried intoReference architectures & standards

ScopePublic sector, defence, banking, energy

Three Metaminds colleagues at a meeting-room screen showing a Quality Engineering workflow — requirements, design review, test planning, automation and lab validation feeding a go/no-go decision and production readiness — beside the line “Quality Engineering for a more resilient tomorrow: trusted digital services for the public, built with rigour” and the sectors served: public services, justice, education and government control.

01Our commitment

Excellence is not a milestone.
It is the standard we hold on every delivery.

The platforms we build carry tax filings, court hearings, school networks and government communications. On systems like these a defect is not a line in a backlog — it is a citizen who cannot file, a hearing that cannot proceed, a public service that is not there on the day it is needed most.

So we pursue excellence in delivery and in operations as one continuous discipline, not two separate phases. It begins at the first architecture review and it does not end at go-live: we design for the load of the worst day rather than the average one, we prove technology in our own lab before it touches a client estate, and we stay with the programme afterwards — because a system is only ever as good as the way it is run.

And we put our clients' needs ahead of our own preferences: the right architecture for the mission rather than the most convenient one, independent advice on technology choices, and documentation and training that leave client teams genuinely able to operate what we have built. Progress is a long-term commitment. So is the quality of the systems that carry it.

—Quality engineered in at design time, not inspected in at the end

—The client's mission ahead of our technology preferences

—Proven in the lab before it ever reaches production

—Ownership that continues past go-live, into day-two operations

02Overview

On critical systems,
defects are not tickets.

Quality is often reduced to functional testing at the end of a project, when architectural decisions can no longer be changed. We apply best practice in architecture design as an engineering discipline — reviewed early, verified continuously, and validated against the real conditions the system will meet.

—Review against known failure modes

—Contract, integration and performance gates

—Peak-day load simulation

—Technology proven in the lab first

03Services

Five practices,
applied from design to day two.

Architecture review

Design assessment against resilience, security and operability criteria — carried out while the design can still change, and recorded as decisions rather than opinions.

Test automation

Verification wired into GitLab pipelines: contract, integration, performance and security gates that a release must pass before it can progress.

Performance & load validation

Peak-day simulation — electoral load, tax deadlines, exam periods — so capacity is proven against the worst day, not an average one.

Technology validation

New platforms proven in the innovation lab before entering a client estate, with the integration risks found in our environment rather than theirs.

Standards & documentation

Reference architectures and operating standards that scale across programmes, so the second delivery starts from what the first one proved.

04How we work

Four gates between a design
and a system we will stand behind.

Open full-size diagram →

Each gate is a stage in one delivery chain, not a separate exercise. Work that has not cleared the gate behind it does not move on — and what operations learn, along with what the lab proves, returns to the design gate instead of being written off as experience.

Meta Quality Engineering — the four gates in one left-to-right delivery chain: 01 Design (architecture review, failure-mode analysis, security and compliance review, operability review, recorded decisions), 02 Build (source of truth, pipeline stages, contract and integration tests, dependency and vulnerability scanning, artefact provenance, policy as code), 03 Prove (disposable environment per run, peak-day load simulation, failover and disaster-recovery rehearsal, innovation lab validation, client acceptance), and 04 Operate (GitOps reconcile, production clusters, an observability plane, trace and log backends, post-incident analysis), with a feedback loop returning findings from operations and the lab to the design gate, and nothing deploying to production except through Git.

05Methodologies

How the work is run,
not only how it is built.

Open full-size workflow →

Technology changes from one programme to the next; the way the work is run does not. These are the methods behind the delivery — how scope is agreed, how a team keeps its rhythm, how a change reaches production, and how a service is run once it is there. The workflow below shows which discipline is doing what, in which phase.

Meta engineering workflow end to end — a swimlane chart with six phases left to right (Discover, Design, Build, Verify, Release, Operate) across four lanes: Programme management scopes, plans, decides and reports; Engineering designs and builds; Quality Engineering proves it before it ships; Platform and Operations runs it. What Operate learns re-enters Discover, on a cadence of daily stand-up, a sprint demo every two weeks, a release train, a monthly service review and a steering committee.

Project & programme management

Scope agreed in writing, a plan with dates that someone owns, and a forum where a decision can actually be taken rather than deferred — iterative or staged, whichever the programme needs.

Agile deliveryScrumKanbanWaterfallMilestone & release planningChange controlSteering committee

Delivery & engagement

How a programme starts and how it lands: what the client needs, in their words, turned into something a team can build, accept and operate.

Discovery workshopsRequirements traceabilityMoSCoW prioritisationDefinition of readyDefinition of doneStaged cutoverPilot before rollout

Engineering practice

The habits that keep a codebase reviewable and a decision retrievable two years after the person who made it has moved on.

Architecture decision recordsPeer code reviewTrunk-based developmentShift-left testingTest pyramidDocumentation as code

DevOps & SRE

Delivery treated as an engineered system in its own right: repeatable, reversible, and observable from the very first deployment.

CI/CDInfrastructure as codeGitOpsCanary releaseBlue-green releaseObservability by defaultRunbooks & on-callError budgets

Service management

What happens after go-live, written down before go-live — so the first incident is handled by a process rather than by whoever answers.

ITIL-aligned incident managementProblem managementChange managementSLA & escalation pathsCapacity managementBusiness continuity & DR

Security & compliance by design

Controls designed in at the first review, evidenced continuously through delivery, and auditable on request rather than reconstructed later.

Threat modellingLeast privilegeSecure SDLCSegregation of dutiesAudit trail & evidence packData protection by design

06End to end

One programme,
from mobilisation to steady state.

The gates say what must be true before work moves on; the methods say how the work is run. This is the shape of the programme itself — the ten stages a delivery passes through, and what has to be finished at each one before the next begins.

01MobilisationTeam, environments, access and ways of working agreed in the first weeks, so delivery does not begin by waiting.

02DiscoveryBusiness processes, constraints and success criteria written down and agreed before any design work starts.

03Design authorityArchitecture reviewed and signed off against resilience, security and operability criteria, with the decisions recorded.

04BuildIterative sprints with a working demonstration every cycle. Nothing is ever reported as ninety per cent done.

05IntegrationConnected to the systems it has to live beside, in an environment that behaves like the real one.

06AcceptanceRun by the client’s own operators, on their scenarios, against criteria agreed in advance rather than negotiated afterwards.

07PilotA limited, reversible first rollout, watched closely, with the rollback path tested rather than assumed.

08RolloutStaged by site or by cohort — each stage with its own go/no-go decision and its own way back.

09HypercareHeightened support in the weeks after go-live, with the delivery team still on the line rather than already reassigned.

10HandoverDocumentation, runbooks and role-based training, then a support model the client’s own team genuinely owns.

07Technology validation

Proven in a lab,
not on citizens.

Metaminds runs an innovation lab where new technologies are permanently tested and validated. A platform earns its place in a client estate only after it has been built, broken and rebuilt in our own environment — with the integration risk absorbed by us rather than discovered by a public institution in production.

Build it end to endThe technology is stood up in full, integrated with the components it will have to live beside — not evaluated from a datasheet or a vendor demonstration.

Break it deliberatelyNode loss, network partition, certificate expiry, storage saturation: the failures we expect the system to survive are caused on purpose while the stakes are ours alone.

Write down what it costsOperational effort, upgrade path and skills required are recorded, so a client adopts a technology knowing what running it will ask of their team.

Turn it into a standardWhat the lab proves becomes a reference architecture and an operating standard — reusable across programmes instead of rediscovered on each one.

08Where it is proven

Programmes that were
validated before they went live.

Public sector · Sovereign cloud

Government Cloud

A sovereign private cloud for the Romanian public sector — over 500 servers across four national data centres, built end to end on Red Hat OpenShift and OpenStack, with automated CI/CD for the applications that run on it.

National Tax Administration Agency

Protecting applications at scale.

The SPV platform and electronic archive: 150,000+ users, 500,000 accesses a day, 150 million files migrated, and over 100 applications protected across two data centres.

Architecture reviewed,tested and validated before production.

Excellence is not a milestone.It is the standard we hold on every delivery.

On critical systems,defects are not tickets.

Five practices,applied from design to day two.