Use cases

Use cases

Situations that come up often and how I approach them.

These are typical scenarios, described as examples. They are not real clients and report no measured results.

A custom application your team can maintain

Software development and engineering

Situation

A company needs an internal application with APIs to other systems. It has no large development team and fears depending on a supplier who keeps the code.

Approach

  1. Essential requirements and boundaries between components, with decisions recorded.
  2. Building in small steps with automated tests and review.
  3. A release pipeline with dependency checks and an SBOM.
  4. Documentation and handover to the team, with the code in its own repository.

Expected outcome

The code belongs to the client, has tests and documentation and can evolve with anyone.

A Kubernetes cluster stuck on an unsupported version

Kubernetes and cloud native platforms

Situation

A team runs a cluster built years ago by someone who has left. Nobody dares to upgrade it, component versions have drifted and the support deadline is close.

Approach

  1. Inventory of versions, APIs in use, add-ons and dependencies.
  2. A test cluster with the same components and a rehearsed upgrade.
  3. A stepwise plan with snapshots, change windows and rollback.
  4. A documented procedure and handover to the team.

Expected outcome

Upgrading becomes a known, repeatable procedure rather than a risky event.

Manual, slow releases that differ between environments

Orchestration and automation

Situation

Every release needs a sequence of manual steps. Environments differ, errors surface in production and only two people know how to do it.

Approach

  1. A map of the steps from commit to production.
  2. Pipelines as code (Jenkins or CI) and configuration with Ansible.
  3. GitOps delivery with environments defined in a repository.
  4. Alerts and automatic rollback for the most common failures.

Expected outcome

The same release repeats identically everywhere and no longer depends on one person.

An AI agent for internal support, with permissions and controls

AI engineering and agentic systems

Situation

A company wants an assistant that answers from internal documents and performs a few actions in its systems. It fears wrong answers, excessive access and runaway cost.

Approach

  1. Definition of the task, readable data and permitted actions.
  2. A prototype with tools (MCP or APIs) and a set of evaluations on real cases.
  3. Least privilege, tracing, cost limits and human approval for sensitive actions.
  4. Quality measured before every change.

Expected outcome

Quality is measured, the agent cannot do what it was not allowed to do and costs are visible.

Moving a legacy application to the cloud without stopping it

Replatforming and cloud migration

Situation

A critical application runs on end-of-life servers. The code has few tests, documentation is thin and a long outage is not possible.

Approach

  1. Assessment: dependencies, data, risks and costs.
  2. Choice of strategy (rehost, replatform or refactor) per component.
  3. Characterisation tests and a pilot on a low-risk component.
  4. Migration in waves with the rollback plan ready.

Expected outcome

The migration proceeds in small, reversible steps with the service always on.

A second opinion before a tender or a large investment

Assessment and second opinion

Situation

An organisation is about to choose a platform or a supplier and wants an independent review of architecture, security and cost.

Approach

  1. Gathering context, goals and constraints.
  2. Review on the real material: diagrams, configuration, contracts.
  3. Risks classified by impact and likelihood.
  4. A short document with priorities and next steps.

Expected outcome

The decision is made with a clear picture of what is solid, what is at risk and what to do first.

Home automation that works without internet

Home automation and IoT

Situation

A building has devices from different brands, separate apps and dependence on manufacturers' clouds. When the network drops, lights and climate stop responding.

Approach

  1. A survey of devices, protocols and network.
  2. A dedicated device network, separate from the main one.
  3. A local MQTT broker and Home Assistant, with Node-RED for flows.
  4. Planned updates and backups; cloud only where needed.

Expected outcome

Essential functions stay active locally and data stays on site.

Let's talk