Case studies

Case 01 · 2026 · open source

mdjira

An open-source Claude Code skill that turns rough markdown product briefs into properly-sized Jira backlogs — INVEST-compliant stories, modified-Fibonacci sizing, BDD acceptance criteria, full epic / story / subtask hierarchy.

Status

Shipped 2026-04-28

Distribution

PyPI · mdjira

Source

github.com/mindaugasnakrosis/mdjira

Write-up

Medium · 2026-04-29

Stack

Python · Jira REST API · Claude Code skill

Headline result

48 Jira tickets generated in five minutes from a single deliberately rough markdown product brief. 17 stories totalling 91 points; sizing distribution 1×2pt, 3×3pt, 8×5pt, 5×8pt — zero 13s. Run on a representative product brief, 2026-04

Tickets created

48 in Jira (epics, stories, subtasks).

Stories

17, totalling 91 story points.

Sizing distribution

1 × 2pt · 3 × 3pt · 8 × 5pt · 5 × 8pt · zero 13s.

Priority spread

1 Highest · 5 High · 9 Medium · 2 Low. Defensible, not flat.

Time to backlog

~5 minutes from markdown to live Jira tickets.

Methodology

The skill is not a wrapper around a generic LLM call. It encodes specific, citable practitioner standards and refuses to produce output that violates them.

1. Story shape — INVEST

   Independent, Negotiable, Valuable, Estimable, Small, Testable. As set out by Bill Wake in XP123 (2003) and refined by Mike Cohn in User Stories Applied. Each generated story is checked against all six.

2. Sizing — modified Fibonacci

   1, 2, 3, 5, 8, 13, 20, 40, 100, per Cohn. The skill enforces the practitioner rule that a 13 is a smell and decomposes anything that lands there. The result above shows the rule in effect: zero 13s across 17 stories.

3. Acceptance criteria — Given / When / Then

   As introduced by Dan North in Introducing BDD (2006). Each story carries explicit criteria, not vague success conditions.

4. Hierarchy — epic / story / subtask

   Atlassian's epic / story / subtask hierarchy, with one anti-pattern explicitly suppressed: the "Miscellaneous Bug Fixes" epic that becomes a permanent dumping ground.

5. Decomposition — Pichler's split axes

   Roman Pichler's compound-story decomposition: split by workflow step, by data variation, by interface, by CRUD, by non-functional concern (see Pichler's notes). The skill picks a split axis and explains the choice.

Case 02 · 2026 · open source

azure-costs-analyzer

A read-only Claude Code skill that runs a 20-minute Azure cost review on any tenant — fifteen citation-grounded rules, eighteen collectors, an HTML+Markdown report. Built for portfolio operators who want one repeatable agent across every portco's tenant, not a £15k consultant deck per company.

Status

Shipped 2026-05-04

Source

github.com/mindaugasnakrosis/azure-costs-analyzer

Write-up

Medium · 2026-05

Stack

Python · Azure CLI · Pydantic · Claude Code skill · MIT-licensed

Headline result

£5,436 – £7,369 / month identified savings on a tenant doing roughly £30k/month in Azure spend — roughly 3× Azure Advisor's published recommendation ceiling for the same tenant. Real run · UK-based Azure tenant · 2026-05

Cost rules

15, each citing a committed Microsoft / FinOps Foundation source.

Collectors

18, all routed through one read-only gate that rejects 33 forbidden write verbs before subprocess.

Knowledge corpus

14 documents, frontmatter-versioned with source URL, retrieval date, and SHA256.

Tests

227 passing (1 skipped — real-tenant smoke test gated on env var).

Output

report.md + report.html (print-friendly CSS) + findings.yaml.

Wall-clock

~20 minutes for a tenant with a few dozen subscriptions.

Architectural bets

1. Read-only is a guarantee

   Single function (azcli.run_json) gates every Azure CLI call. Twenty-three unit tests verify it rejects every one of 33 forbidden write verbs before subprocess is reached. Adding new collectors does not loosen this.

2. Citation-grounded knowledge

   Every rule declares KNOWLEDGE_REFS pointing at committed .md files. A rule that cites a missing document fails to load. The model computes; the rule cites. Refresh script tracks upstream SHA256 drift.

3. Severity × Confidence as independent axes

   "We think this £4k reservation is wasted" gets handled differently from "this £4 IP is definitely orphaned". Single-axis lists hide that distinction; the report keeps it.

4. Forecast over snapshot

   Underused-reservation findings combine spend, utilisation, and term-remaining (read from expiryDateTime) into one forward-looking £ figure — e.g. "£4,558 – £5,535 between now and expiry" on a 9-month-remaining reservation. Advisor doesn't combine those axes.

5. Savings as ranges, not point estimates

   Every monetary recommendation comes with a non-empty assumption string explaining what's not netted out: negotiated discounts, reservation coverage, regional price drift. The range itself is the answer.

Case 03 · Oct 2024 – Feb 2025 · VP of Technology

Derivatives trading platform

VP of Technology for a buy-side FinTech derivatives platform. Owned the architecture for real-time trade execution, the Java backend on Azure, and the integration of agentic AI into trading workflows.

Sector

FinTech · derivatives · buy-side

Role

VP of Technology

Tenure

Oct 2024 – Feb 2025

Stack

Java · Azure · FIX protocol · Kubernetes · IaC · agentic AI

Client

Confidential

What I owned

• Architected and implemented FIX protocol messaging infrastructure for real-time trade execution and order management.
• Designed and deployed Java-based backend systems on Azure cloud infrastructure for trading-grade scalability and reliability.
• Pioneered integration of agentic AI into trading workflows and operational tooling — early production deployment, not pilot.
• Established cloud-native architecture patterns on Azure: microservices, containerisation, infrastructure-as-code.
• Implemented security and compliance frameworks aligned with financial-services regulatory requirements.
• Built and managed a cross-functional engineering team; ran the technical liaison between CEO/CPO and engineering, translating business requirements into technical roadmaps.
• Drove platform-evolution decisions in a live trading environment — balancing innovation against system stability.

Client name confidential — references on request

Case 04 · May 2021 – Oct 2024 · 3 years 6 months

Cult Wines · asset trading platform

Front-office architect on the green-field asset-trading platform for an alternative-investments firm. Drove the full-stack of the front office across React, Next.js, React Native, and an Azure-native event-driven backend.

Sector

Alternative investments · asset trading

Role

Front-office Architect (full-stack)

Tenure

May 2021 – Oct 2024

Stack

React · Next.js · React Native · Auth0 · Databricks · Azure Functions · CosmosDB · Service Bus · AKS · Terraform · GraphQL/Apollo

Client

Cult Wines · London

What I owned

• Built a green-field asset trading platform with React and React Native, sharing logic across web and mobile to reduce delivery time and bug surface.
• Built a Next.js web app to meet SEO requirements where they mattered.
• Implemented Auth0 MFA across multiple platforms and applications.
• Reorganised the data-pipelines strategy and helped introduce Databricks on Azure.
• Introduced an OpenAPI strategy with Azure API Management.
• Led the front-office API layer with Azure Functions and a horizontally-scalable CosmosDB tuned for high read throughput.
• Set up an event-driven API strategy on Service Bus.
• Initiated Cypress end-to-end smoke testing for the new systems.
• Led migration of an old, technically-deprecated core business system onto the new platform.
• Helped the DevOps team migrate from PowerShell to Terraform-based IaC.
• Migrated app services into Azure Kubernetes Services (AKS).
• Built numerous microservices for operational and third-party integration needs.
• Introduced test-driven development with deployment gates blocking unsecure or untested code.
• Implemented a GraphQL layer on both UI and backend with Apollo.