Engineering case studies

Engineering decisions under real constraints.

These are real engineering situations, described at the level that can be shared responsibly. The emphasis is on the problem, the decisions and the resulting operational state.

Featured work

Four situations where the constraint shaped the engineering response.

Anonymised client case

Building an SRE operating model for an always-on production platform

Situation: A production platform moved into continuous operation. Its support model had to work across shifts rather than depend on whoever remembered the last change.
Constraint / engineering problem: On-call, handover, ownership and incident responsibility needed explicit boundaries, including where SRE responsibility ended.
What we did: We defined shifts, on-call coverage, handover, escalation and decision rights. The escalation chain ran from on-shift engineer to on-call, profile lead, platform owner and CTO.
Result: Production operation could be described through roles, state and processes instead of personal memory or heroics.
What this demonstrates: Reliable operations need explicit authority and a handover path, not only technically capable people.

Anonymised client case

Diagnosing production database saturation under a concurrency spike

Situation: A production database approached CPU saturation. Health checks failed and several external consumers were affected.
Constraint / engineering problem: Restoring service did not explain the failure. The observed symptoms had to be separated from the concurrent workload and a slower critical database path.
What we did: After service was restored, we continued the causal analysis. We distinguished immediate mitigation from corrective action and kept the evidence chain separate from assumptions.
Result: The incident record captured the workload change and the database-path finding without treating recovery as proof of root cause.
What this demonstrates: Service restoration and root-cause analysis are different milestones.

Gronnark engineering case

Recovering 17 Git repositories after loss of administrative access

Situation: Administrative access to an old GitHub account was lost and account recovery was not possible. Seventeen repositories needed to be preserved before any migration.
Constraint / engineering problem: A transfer attempt could not be allowed to become the only copy of repository history or refs.
What we did: We captured refs, history and trees; created git bundles and branch archives; recorded SHA256 manifests; and checked bundles, object integrity, clean clones, submodules and LFS dependencies before migrating.
Result: All 17 repositories were restored in a new organisation. Relevant refs were verified SHA-for-SHA; the old organisation remained a historical source.
What this demonstrates: Preserve first. Migrate second.

Anonymised client case

Replacing fragile remote support for a dental practice

Situation: A dental practice relied on a Windows practice-management system and a local database. Its consumer remote-access tool began dropping support sessions.
Constraint / engineering problem: The database and internal services could not simply be exposed to the Internet to make remote desktop more convenient.
What we did: We designed remote connectivity separately from the application: an encrypted tunnel, a controlled external entry point and VPN access for authorised engineers before administrative protocols could be used.
Result: The proposed access model kept the local database non-public and made network entry an explicit control, providing a safer architecture for replacing the unreliable remote-support path.
What this demonstrates: A remote-desktop symptom can be an access-architecture problem.

More engineering cases

Separate problems, each with a concrete change in how the system or operation is managed.

Anonymised client case

Redesigning incident management around explicit ownership

Situation: Severity, ownership, escalation and the definition of done were ambiguous.
What changed: We introduced a severity model, Owner and Commander roles, escalation, incident and postmortem completion criteria, corrective actions and action owners in one incident record.
Result: Restored production was no longer the sole criterion for closing an incident.

Anonymised client case

Separating SRE ownership from application ownership

Situation: SRE participation in incidents was becoming an expectation that SRE would find the cause of every application failure.
What changed: We separated detection, impact assessment, coordination and escalation from component-level technical ownership.
Result: Responsibilities could be assigned to the people with the authority and context to act. Responsibility without control is not ownership.

Anonymised client case

Turning shift handover into an operational system

Situation: Operational state was scattered across Slack, Jira, Confluence and individual conversations.
What changed: We standardised the handover of active incidents, unfinished changes, expected events, risks, pending actions and owners.
Result: The operational summary became a defined system capability rather than an informal message between shifts.

Anonymised client case

Investigating health-check failures without inventing a root cause

Situation: Brief health-check failures and connection-related evidence were followed by quick service recovery.
What changed: We documented observed facts, supporting evidence, a plausible mechanism and what remained unknown as separate statements.
Result: The postmortem preserved a precise boundary of knowledge instead of presenting an unproved cause as certainty.

Gronnark engineering case

Rebuilding CI/CD trust after repository migration

Situation: Moving the repositories did not move the permissions and identities on which deployment depended.
What changed: We rebuilt Actions, the self-hosted runner, OIDC and AWS trust, rotated the deploy SSH key and secret, then ran an isolated Actions-to-runner-to-AWS-to-SSH smoke test. Temporary firewall access was removed afterwards.
Result: The deployment trust chain was verified end to end, rather than inferred from a green pipeline.

Gronnark engineering case

Building an isolated stage environment before changing production

Situation: Website changes expanded beyond HTML and CSS into multilingual delivery, edge logic, CloudFront, WAF, geography hints and automation.
What changed: We built a stage environment with separate infrastructure state, an edge preview and its own deployment flow. Production promotion remained a separate decision.
Result: Changes could be tested against a deployed environment without making each testing error a production change; stage stayed out of search indexing.

Gronnark engineering case

Designing international delivery without forced geo-redirection

Situation: Delivery across markets needed more than a list of supported countries.
What changed: We defined Local, Regional and International profiles covering remote and on-site work, travel, working-hours overlap, physical intervention and service availability. CloudFront country data is only a hint; the visitor chooses.
Result: The model states what can be considered without implying a local office, permanent presence or forced regional redirect.

Gronnark engineering case

Rebranding a technical company without breaking operational continuity

Situation: The move from Aize.IT to Gronnark touched domains, email, Workspace, GitHub, DNS, certificates, automation, documentation and client relationships.
What changed: We planned domain transitions, redirects, email aliases and migration, DNS and DKIM changes, a public transition statement and gradual infrastructure-identity changes.
Result: Existing commitments and operational access could continue through a change of name. A technical rebrand is also a migration project.

On confidentiality and scope

Client case studies are anonymised where contractual or operational confidentiality requires it. Some studies describe separate engineering problems addressed within a longer client engagement; they do not represent twelve separate clients.

Have a situation that looks familiar?

Tell us what is happening, what must keep working and where the uncertainty begins.

Discuss the situation