The software page defines case studies as typed inline data with two layers of badges

The software service page has a Case Studies section rendering three projects — Blind Drummer, the Live Interactive Music Platform, and the TikTok AI Live Assistant. The data for these sits in a const array called caseStudies at the top of the page file, not in the central data/projects.ts showcase file. Each entry has six fields — title, category, an optional url, description, a metrics array, and a techStack array. The separation is deliberate. The projects.ts file stores detailed structured breakdowns with challenge, approach, outcome, and techDeepDive sections for the portfolio showcase. The inline caseStudies array stores lightweight marketing summaries designed for scanning, not reading. Different audiences, different levels of detail, different files. Each case study renders inside a glass card. The category label — Product Build, Real-Time Product, AI Product — sits at the top in uppercase tracking-wider text using the service accent colour. Below it the title in bold white. If the project has a live URL, a Visit arrow link appears in the top-right corner with target blank and noopener noreferrer. The description follows in muted text. Then two rows of pills. The first row renders metrics — Idea to launch in 11 days, Sub-second latency, Real-time AI responses — as accent-coloured badges with a ten-percent opacity background. The second row renders the tech stack — Next.js, Prisma, Stripe, WebSockets, Claude API — as muted pills with a secondary background colour. Two layers of badges on every card. The accent layer tells you what the project achieved. The muted layer tells you what it was built with. A visitor scanning the page sees the outcomes first and the technology second, which is the right priority for someone deciding whether to hire an engineer.