Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/sys-core/llms.txt

Use this file to discover all available pages before exploring further.

The caseStudies.js module exports an array c of case study objects rendered in the Case Studies section of the portfolio. Each entry is framed as a military mission report or flight operations briefing: a structured after-action review with a defined objective, a chronological mission timeline, documented anomalies encountered in the field, and a measured outcome. The metaphor maps naturally to the structure of a real engineering post-mortem and encourages honest, detailed storytelling about complex projects.

Data Shape

interface MissionPhase {
  phase: string;       // Phase label, e.g. "T-MINUS 6M" or "PHASE 1"
  description: string; // One-sentence summary of work in that phase
}

interface CaseStudy {
  id: string;             // Unique identifier, e.g. "cs1"
  title: string;          // Mission name + subtitle, e.g. "PROJECT ORION: ..."
  duration: string;       // Human-readable duration, e.g. "6 MONTHS"
  crew: string;           // Team composition, e.g. "4 ENGINEERS, 1 DESIGNER"
  techDeployed: string[]; // Technologies used on the mission
  objective: string;      // The goal: what problem were you solving?
  preFlight: string;      // Pre-mission situation analysis / problem statement
  timeline: MissionPhase[]; // Ordered phases from start to launch
  anomalies: string;      // Challenges, blockers, and how they were resolved
  outcome: string;        // Measurable results and delivery summary
  future: string;         // Planned next steps or follow-on work
}

Field Metaphor Guide

FieldMission MetaphorPlain-Language Meaning
titleMission designationProject name and subtitle
durationMission clockTotal elapsed time from kick-off to delivery
crewCrew manifestTeam size and roles
techDeployedDeployed systemsTechnology stack
objectiveMission objectiveWhat you set out to build or fix
preFlightPre-flight analysisState of the system before work began; why action was needed
timelineMission timelineChronological phases of the project
anomaliesAnomalies detectedTechnical blockers, surprises, and how they were resolved
outcomeMission outcomeMeasurable results delivered
futureFollow-on missionPlanned improvements or next phase

Current Entries

cs1 — PROJECT ORION: E-Commerce Replatforming

FieldValue
Duration6 MONTHS
Crew4 ENGINEERS, 1 DESIGNER
Tech DeployedNext.js, Shopify Storefront API, Tailwind CSS, Framer Motion
ObjectiveMigrate a legacy monolithic e-commerce platform to a headless architecture to improve Lighthouse scores and conversion rates.
Pre-FlightInitial scans revealed a 4.5s Time to Interactive and a bloated 2 MB JavaScript bundle. The legacy system was tightly coupled, making incremental updates dangerous.
AnomaliesSevere rate-limiting from the inventory API during high-traffic load testing. Mitigated by implementing a Redis caching layer at the edge.
OutcomeReduced TTI to 1.2s. Conversion rate increased by 18%. Weekly deployments instead of monthly.
FuturePersonalised product recommendations using edge middleware and a lightweight ML model.
Mission Timeline — PROJECT ORION
PhaseDescription
T-MINUS 6MArchitecture design and technology selection.
T-MINUS 4MCore component library construction and Shopify API integration.
T-MINUS 2MCheckout flow implementation and edge-case handling.
T-ZEROStaged rollout to 10% of traffic, monitoring for anomalies.

cs2 — OPERATION NEBULA: Real-time Collaboration Tool

FieldValue
Duration3 MONTHS
Crew2 ENGINEERS
Tech DeployedReact, Yjs, WebRTC, Canvas API
ObjectiveBuild a local-first, real-time collaborative whiteboard that works offline and syncs when reconnected.
Pre-FlightStandard WebSocket approaches failed under poor network conditions. A robust conflict resolution strategy was required.
AnomaliesMemory leaks during prolonged sessions with thousands of vector objects. Resolved by implementing spatial hashing and culling off-screen elements.
OutcomeA resilient collaborative tool where users can work offline indefinitely and sync seamlessly upon reconnection.
FutureAdding voice channels and cursor presence history.
Mission Timeline — OPERATION NEBULA
PhaseDescription
PHASE 1CRDT evaluation and local storage wrapper implementation.
PHASE 2Canvas rendering engine optimisation for 60fps panning.
PHASE 3WebRTC signalling server and peer-to-peer sync logic.

Adding New Entries

  1. Open data/caseStudies.js.
  2. Append a new object to the array following the cs{n} id convention.
  3. Frame the title as a mission codename followed by a colon and a plain subtitle, e.g. "MISSION ATLAS: Design System Overhaul".
  4. Write preFlight as a concise situation report — describe measurable symptoms of the problem, not just a vague statement that “things were slow.”
  5. Build the timeline array with one phase object per major milestone. Use mission-clock notation (T-MINUS 3M) for time-boxed projects or PHASE {n} for iterative work.
  6. Document real anomalies in the anomalies field — specific technical blockers and their resolutions are more compelling than generic challenges.
  7. Populate outcome with concrete, quantified results wherever possible.
// data/caseStudies.js  — append inside the array
{
  id: "cs3",
  title: "MISSION ATLAS: Design System Overhaul",
  duration: "4 MONTHS",
  crew: "2 ENGINEERS, 1 DESIGNER",
  techDeployed: ["React", "Storybook", "Radix UI", "Tailwind CSS", "Chromatic"],
  objective:
    "Consolidate five fragmented component libraries used across internal tools "
    + "into a single, versioned design system with full accessibility compliance.",
  preFlight:
    "Audit revealed 23 different Button variants across the codebase with "
    + "inconsistent focus states and no dark-mode support. On-boarding a new "
    + "engineer took two weeks just to understand the component landscape.",
  timeline: [
    {
      phase: "PHASE 1",
      description: "Component audit, token extraction, and design-system architecture.",
    },
    {
      phase: "PHASE 2",
      description: "Core primitives built on Radix UI with full ARIA compliance.",
    },
    {
      phase: "PHASE 3",
      description: "Storybook documentation, Chromatic visual regression testing.",
    },
    {
      phase: "PHASE 4",
      description: "Incremental migration of all five tools to the new library.",
    },
  ],
  anomalies:
    "Radix UI's asynchronous focus management conflicted with an existing "
    + "keyboard-shortcut system. Resolved by wrapping Radix's FocusScope with "
    + "a custom context that exposes an escape hatch for global hotkeys.",
  outcome:
    "Reduced per-component implementation time by 60%. Zero WCAG 2.1 AA "
    + "violations on audit. New-engineer on-boarding time cut from two weeks "
    + "to two days.",
  future: "Publish the library as an open-source package with a public docs site.",
}
The anomalies field is the most read section of a case study. Recruiters and senior engineers look for evidence of rigorous problem-solving. Be specific: name the tool, describe the failure mode, and explain your fix.

Field Reference

id
string
required
Unique identifier for the case study. Follow the cs{n} pattern (e.g. "cs1", "cs3").
title
string
required
Mission designation string rendered as the case study heading. Convention: "CODENAME: Plain Subtitle" (e.g. "PROJECT ORION: E-Commerce Replatforming").
duration
string
required
Human-readable project duration in all caps, e.g. "6 MONTHS" or "3 MONTHS". Displayed in the mission metadata block.
crew
string
required
Team composition in all caps, e.g. "4 ENGINEERS, 1 DESIGNER". Gives visitors context on team size and role distribution.
techDeployed
string[]
required
Array of technology names used on the project. Rendered as tag chips in the mission header.
objective
string
required
One to two sentences stating the mission goal. This is the “north star” of the case study — everything else in the document should connect back to it.
preFlight
string
required
Pre-mission situation analysis. Describe the state of the system or problem before work began, ideally with measurable data points (latency, bundle size, error rate). This is the engineering equivalent of a problem statement.
timeline
MissionPhase[]
required
Ordered array of mission phases from project kick-off to delivery. Each phase has a phase label (e.g. "T-MINUS 6M", "PHASE 1") and a single-sentence description of the work completed.
timeline[].phase
string
required
Phase label. Use mission-clock notation (T-MINUS 6M, T-ZERO) for time-boxed projects or sequential labels (PHASE 1, PHASE 2) for iterative work.
timeline[].description
string
required
One-sentence summary of the work completed during this phase.
anomalies
string
required
A paragraph documenting significant technical blockers, unexpected failures, or risks encountered during the project, and how each was resolved. Be specific — generic challenges are far less compelling than named failures with concrete fixes.
outcome
string
required
The measurable result of the project. Quantify wherever possible: latency reductions, conversion rate lifts, bundle size savings, deployment frequency improvements.
future
string
required
Planned follow-on work or the next phase of the project. Even a one-sentence forward-looking statement demonstrates that you think beyond the immediate delivery.

Build docs developers (and LLMs) love