The Case Studies page (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/apursley2012/magical/llms.txt
Use this file to discover all available pages before exploring further.
/case-studies) is titled Deep Rituals and subtitled “Comprehensive Case Studies.” It presents two detailed case studies structured around the alchemical metaphor of a ritual: identifying a problem, defining a goal, executing a process, and measuring results. Each ritual is a long-form section with structured data panels.
Visual & UX Overview
Ritual Heading Motif
Each case study is introduced with a stylised “Ritual I” / “Ritual II” label using the same Roman numeral treatment as the Home page navigation cards, reinforcing visual consistency across the site. Section headings use
font-serif in mystic-mint.Problem / Goal / Process / Results Structure
Every ritual follows the same four-part structure. This is not a visual layout with tabs — it is a vertical scrolling narrative with clearly delineated sub-headings, giving the reader a story arc from pain point to solution.
Results Metrics Panel
The Results section of each ritual renders a row of metric cards showing a combined before/after value (e.g., ”14s → 0.8s”) and a label. These are driven by a hardcoded array of result objects.
Entrance Animation
Both ritual sections are wrapped in a single
motion.div with initial: {opacity: 0, y: 20} → animate: {opacity: 1, y: 0}, duration: 0.8s, applied on page mount.Ritual I — The Apothecary Migration
Subtitle: “Legacy to React Transmutation”Problem in detail
Problem in detail
The three core symptoms driving the migration were:
The existing system was built on jQuery and spaghetti PHP.
| Symptom | Impact |
|---|---|
| 14-second load time | Staff opened the tool, walked away, forgot about it |
| Concurrent edit corruption | Two staff members editing the same record simultaneously caused data corruption |
| Pen-and-paper reversion | Critical stock counts were being tracked outside the system, defeating its purpose |
Goal
Goal
Architect a modern, real-time React application that could handle offline capabilities for when the shop’s Wi-Fi inevitably dropped, while maintaining a UI that felt organic and aligned with their brand.
Technical process
Technical process
The migration began by mapping existing data structures. The key step was an ETL (Extract, Transform, Load) script written in Node.js to cleanse the data before seeding the new PostgreSQL database. A code comment in the source references this as the “cleansing ritual.”The React frontend was built in parallel with the legacy system, and both ran simultaneously during the transition period.
Results
Results
| Metric | Result |
|---|---|
| Load Time | 14s → 0.8s |
| Data Integrity | 100% |
| PWA Support | Offline / PWA |
| Staff Adoption | +40% |
Ritual II — Grimoire UI Kit
Subtitle: “Design System Architecture”Problem in detail
Problem in detail
The fragmentation audit revealed:
Visual inconsistency was eroding user trust, and development velocity was slowed by constant recreation of basic components.
| Pattern | Variation Count |
|---|---|
| Primary button | 14 unique implementations across 3 tools |
| Date picker | 6 different implementations with incompatible APIs |
Goal
Goal
Establish a single source of truth. A living spellbook of components that all tools could adopt.
Technology decisions
Technology decisions
Tools used:
Why Radix UI primitives?
Radix provides fully accessible, unstyled headless components. By building on Radix, all keyboard navigation, ARIA roles, and focus management was handled automatically, achieving WCAG compliance out of the box without custom accessibility engineering.
| Layer | Technology |
|---|---|
| Component API | React + TypeScript |
| Styling | Tailwind CSS |
| Documentation | Storybook |
| Accessible primitives | Radix UI (Primitives) |
Results
Results
| Metric | Before | After |
|---|---|---|
| Primary button variants | 14 | 1 |
| Date pickers | 6 | 1 |
| A11y compliance | Partial | WCAG 2.1 AA |
| Dev onboarding | ~2 weeks | ~3 days |
Customization
Adding a third case study
Adding a third case study
The two ritual components (
Ritual I and Ritual II) are separate sub-components rendered inside a wrapping motion.div. To add a third, create a new component following the same structure (problem/goal/process/results sections) and add it as a sibling inside the wrapper. Use “Ritual III” as the heading prefix.Updating result metrics
Updating result metrics
The results for each ritual are rendered from a hardcoded inline array of
{ metric, label } objects. Update the metric string (e.g., "14s → 0.8s") and label (e.g., "Load Time") to reflect the correct values. Values are plain strings — qualitative outcomes like "None → PWA" work equally well.Component Dependencies
| Component | Source | Role |
|---|---|---|
BackgroundEffects | components/BackgroundEffects.js | Ambient particle and blur layer |
Navigation | components/Navigation.js | Fixed top navigation bar |
Sigil | components/Sigil.js | Decorative sigil accents in ritual section headers |
motion (Framer Motion) | assets/proxy.js | Page-level entrance animation wrapping both rituals |
The “Apothecary Migration” case study corresponds directly to the Apothecary Inventory project card in the Grimoire (
/projects). Both share the same narrative — the project card shows the outcome; the case study shows the full process.