Introduction

You know Receiptify, right? The thing that turns your Spotify listening history into a crumpled receipt you screenshot and post on your Instagram Story. It's brilliant. Dead simple. Zero AI. Just a clever remix of data you already have.

I was staring at my own Receiptify output one night and thought: okay, this is fun, but what if the output wasn't a receipt? What if it was something you could actually consume? Something physical. Something ridiculous. Something like... a drink recipe generated from your music taste.

That's how Jamutify was born. It's an apothecary-themed web app that pulls your top Spotify artists and tracks, feeds them to an AI herbalist, and spits out a personalized Jamu recipe, Jamu being traditional Indonesian herbal medicine, the kind your grandmother would make with turmeric, ginger, tamarind, and palm sugar. Except now an LLM is the grandmother.

The Problem

Receiptify is visual and static. You look at it, laugh, maybe share it, and move on. I wanted to build something that took the same input, your Spotify data, and produced output you could theoretically act on. Not a visualization. A recipe. With actual ingredients, measurements, and instructions.

But "recipe from music" is an absurdly vague prompt to give an AI. What does Aphex Twin taste like? How many tablespoons of turmeric does a Dua Lipa chorus translate to? If I just threw raw artist names at an LLM and said "make a drink," I'd get back hallucinated nonsense 80% of the time.

I needed a system. A pipeline that could:

Pull the user's actual Spotify data (not mock data, not a gimmick)
Map musical characteristics to real, edible ingredients with cultural grounding
Produce consistent, structured output every time, regardless of which AI model was generating it
Export the result as something shareable

Also: Jamu is a real tradition. I'm Indonesian. This couldn't be some Silicon Valley "we disrupted herbal medicine" nonsense. It had to respect the ingredients, the names, the preparation methods. The AI had to know the difference between kunyit (turmeric) and temulawak (Javanese turmeric), and why you'd use one over the other.

The Solution

Jamutify runs on Next.js 16 with the App Router. Auth is handled by NextAuth with the Spotify provider, requesting exactly one scope: user-top-read. That's it. I don't need your playlists, your library, your followed artists. Just the top 5 artists, top 5 tracks, and their genre tags. Bare minimum.


graph LR
    Spotify["Spotify API"] -->|top artists/tracks| Matrix["Music Matrix"]
    Matrix --> Cache{"SHA-256 Cache"}
    Cache -->|hit| Recipe["Return Cached Recipe"]
    Cache -->|miss| MbokG["Mbok Gem, Gemini"]
    Cache -->|miss| MbokS["Mbok Sae, DeepSeek"]
    MbokG -->|structured JSON| Normalize["Normalize & Validate"]
    MbokS -->|raw JSON| Normalize
    Normalize --> Card["Recipe Card 1080x1920"]
    Card --> Export["html-to-image Export"]
    Card --> Share["Shareable URL"]
    Normalize --> Cache

When you hit "Brew Personalized Jamu," the app fetches your top 5 artists and top 5 tracks from Spotify, collects genre tags, and builds what I call a "music matrix." That matrix gets SHA-256 hashed, and the hash is checked against PostgreSQL. If you've brewed with the same matrix before, your saved recipe comes back instantly. No wasted API call. This small optimization makes the app feel snappy when you re-generate with the same settings.

Two AI Brewers, One Apothecary

The generation pipeline has two AI "brewers" you can choose from. I named them like old Javanese herbalists because, well, the whole thing is already ridiculous and I committed to the bit.

Mbok Gem uses Google Gemini (gemini-2.5-flash) with native structured JSON output via responseSchema. The system prompt is extensive, it maps musical vibes to ingredient categories: deep bass gets earthy turmeric and galangal, rock gets spicy ginger and black pepper, indie gets bittersweet tamarind, hyperpop gets fizzy lemongrass and soda water, and pop gets honey and pandan. Every ingredient comes with a "sonicReason", a witty one-liner linking the herb to a specific artist or track, wrapped in HTML bold tags.

Mbok Sae uses DeepSeek (deepseek-v4-flash) via response_format: { type: "json_object" }. DeepSeek doesn't have Gemini's native schema enforcement, so I had to build a key-normalization layer that handles snake_case, camelCase, and whatever creative naming the model decides on. If the model returns recipe_name instead of recipeName, or qty instead of amount, the normalization layer catches it.


// Key normalization for DeepSeek responses, handles snake_case, camelCase, and creative naming
recipePayload = {
  recipeName:
    parsed.recipeName || parsed.recipe_name || parsed.name || "Aromatic Jamu Melody",
  vibeDescription:
    parsed.vibeDescription || parsed.vibe_description || parsed.description || "...",
  ingredients: (parsed.ingredients || parsed.recipe_ingredients || []).map((ing) => ({
    name: ing.name || "",
    indonesianName: ing.indonesianName || ing.indonesian_name || ing.indonesian || "",
    amount: ing.amount || ing.qty || ing.quantity || "",
    sonicReason: ing.sonicReason || ing.sonic_reason || ing.reason || "",
  })),
};

Fallback Chain: When AI Gets Weird

AI is unpredictable. API keys go missing. Rate limits hit. Models hallucinate. So the whole thing has a fallback chain. If Gemini fails, it falls back to mock recipes. If DeepSeek fails, same thing. If no API key is configured at all, you get five hardcoded vibe-based recipes: grounding (turmeric-tamarind tonic), spicy (red ginger black pepper brew), melancholic (senja tamarind elixir), fresh (lemongrass carbonated soda), and sweet (honey pandan nectar).

The mock recipes aren't lazy either. Each one has fully written sonic reasons, proper Indonesian ingredient names, and practical brewing instructions. The genre-matching logic routes you to the right one based on your music's vibe, rock and metal get spicy, indie and R&B get melancholic, hyperpop and electronic get fresh.

There's also a guest mode that works without Spotify auth. No token? No problem. You pick a vibe and get a mock recipe immediately.

Recipe Cards: The Real Product

The recipe card is where all the effort went. Each one is a 9:16 apothecary label styled like vintage Indonesian medicine packaging, dark moss gradient background, double borders, aged paper textures, a circular "ORIGINAL APOTHECARY RECIPE" seal overlay, and a dynamically generated QR code pointing back to the app.

The card has a header ("JAMUTIFY, Sonic Herbal Apothecary"), the recipe name and calorie count, a table of ingredients with English names, Indonesian names, amounts, and sonic reasons, a "Quick Brew Guide" with numbered steps, a pro tip from the herbalist, and a footer with the user's Spotify avatar and brew date.

Export is handled by html-to-image's toPng() function, rendering the RecipeCard component at 1080x1920, exactly Instagram Story dimensions. Getting this right was surprisingly finicky. Custom fonts and CSS transforms would shift text by a few pixels in the exported PNG compared to what was on screen. I had to lock down every dimension with explicit pixel values and add a 300ms render delay before capture.

The Result

Jamutify is live at jamutify.ariqi.dev, self-hosted on my Proxmox homelab running Coolify, served through Cloudflare Tunnels since I'm behind CGNAT. Everything runs in a Docker container with a multi-stage build.

There's a public grid where everyone's creations show up, you can browse what other people's music tastes taste like. Each recipe has a shareable URL (just append ?recipe=id), so you can drop a link to your brew in a group chat and watch your friends try to figure out what's wrong with you.

The tech stack: Next.js 16, React 19, NextAuth (Spotify provider), Prisma + PostgreSQL, Google Gemini and DeepSeek for generation, Motion for animations, html-to-image for card export, and QRCode for the scannable footer. The whole thing is TypeScript end to end.

Key Takeaways

Structured JSON output from LLMs is great until it isn't. Gemini's responseSchema is rock solid but vendor-locked. DeepSeek's json_object mode works but the key names are unpredictable. If you're building with multiple AI providers, budget time for a normalization layer. It's not glamorous but it's what makes the app reliable.
SHA-256 caching is a tiny feature with outsized impact. Hashing the music matrix means repeat generations are instant and free. Users don't notice it, but they'd definitely notice if every re-brew took 5 seconds and burned another API call.
Fallback recipes aren't a compromise, they're a feature. The five mock recipes are genuinely fun. They work without Spotify, without API keys, without anything. If the AI pipeline is down, the app still delivers something delightful. That's a better UX than an error toast.
Build the stupid idea. Jamutify has no business existing. Nobody asked for AI-generated herbal drink recipes from Spotify data. But it makes people smile, it taught me a ton about structured generation and card export, and it's the project people remember when I show them my portfolio. The "why would you build this" projects are often the best ones.

Receiptify Got Me Thinking: What If Your Spotify Data Generated Drinkable Recipes?