The brief

What the client needed

hitdlaciebie.pl ("a hit for you" in Polish) is a personalized music gift service. A user describes who the song is for, the occasion, the mood — and receives a full original song: custom lyrics, AI-generated vocals, MP3 ready to share.

The product had to work end-to-end without manual intervention: user pays via Shopify, lyrics are generated, music is produced, file lands in the user's personal cabinet. All in Polish, all automated.

The engineering challenge was not building a form. It was building a reliable pipeline where three external AI services (LLM for lyrics, music API, Shopify for billing) hand off to each other correctly under real-world conditions: webhooks that arrive twice, CDN links that expire, test mode that silently does nothing.

Why one LLM is not enough for AI song generation

Single-model attempts failed in both directions. High temperature (creative mode): the lyrics were imaginative but structurally broken — wrong verse lengths, missing chorus markers, inconsistent rhyme scheme. Low temperature (structured mode): the lyrics were formatted correctly but flat and forgettable. The solution was a two-stage pipeline: creativity first, structure second.

Lyrics pipeline

Why two models instead of one

Suno V5.5 — the AI music generator used in production — requires specific formatting: [Verse], [Chorus], [Bridge] tags with consistent line lengths and rhyme patterns. Feed it inconsistent lyrics and the output breaks structurally.

Getting both creativity and structure from a single LLM call required temperature tuning that pulled in opposite directions. The fix was to stop trying.

User prompt (occasion, recipient, mood, style)
  ↓
Gemini 2.5 Flash — temperature 0.8
  ↓ creative draft: vivid imagery, emotional language, raw ideas
Claude Sonnet 4.6 — temperature 0.35
  ↓ structural edit: enforces [Verse]/[Chorus] tags, rhyme scheme, line count
Final lyrics → Suno V5.5 API → MP3

Gemini 2.5 Flash at 0.8 handles the creative layer: it generates emotionally resonant raw content in Polish without worrying about format. Claude Sonnet at 0.35 handles the editorial layer: it takes the draft and enforces exactly the structure Suno expects.

Both calls go through OpenRouter, which means the same pipeline can swap models without changing the API integration. If a better Polish-language model appears, it slots in at stage one with a config change.

Music API selection

Tested four, shipped one

Choosing the wrong music API at launch means rebuilding the pipeline later. I tested all four candidates before committing to production. The architecture is provider-agnostic — all four remain registered. Swapping the active provider is a config change, not a rewrite.

API Polish vocals Structure Reliability Decision
fal.ai / Minimax Weak — vowel-heavy words sounded synthesized Good Stable Rejected
ElevenLabs Music Good timbre No verse/chorus awareness — treats all lyrics as one block Stable Rejected
Udio Promising quality Good Silent failures during testing Rejected
Suno V5.5 Natural Polish phonetics Correct [Verse]/[Chorus] interpretation Consistent Shipped
What broke before launch

Three real production problems

Problem 01
Two days lost to a checkbox in Shopify admin
Token credits were not appearing after test purchases. I reviewed the entire webhook flow: HMAC verification, database writes, token allocation logic — everything was correct. The code had been working from day one. The actual issue: Shopify test mode requires manually clicking "Mark as paid" in the admin panel. Without it, the paid webhook never fires. The code worked. The environment did not behave like production.
Lesson: always verify that test mode fires the same webhooks as production before building on top of it
Problem 02
SSRF vulnerability in the audio proxy
Suno CDN URLs expire within hours. To avoid broken links in user cabinets, I built a /proxy-audio route that re-serves audio from the CDN on demand. The first version accepted any URL as input — a classic Server-Side Request Forgery (SSRF) hole. Fixed with strict URL.hostname validation: only *.suno.ai over HTTPS allowed. This broke legacy fal.ai URLs already stored in the database — the allowlist was extended for backward compatibility.
Fix: whitelist-only URL validation on any proxy endpoint. Never trust user-supplied URLs to internal fetch calls
Problem 03
Shopify fires the same webhook twice
Shopify's webhook delivery is not guaranteed to be exactly-once. Under network instability or timeout, the same orders/paid event can arrive twice. The result without protection: users get double the token credits, orders are processed twice, database records duplicate. Fixed with a unique constraint on shopify_order_id and ON CONFLICT DO NOTHING on insert. The pipeline became idempotent by design — re-running the same webhook has no effect after the first successful write.
Fix: idempotent webhook handling via unique constraint on external ID. Assume any external event can arrive more than once
Key metrics

What shipped

  • 2 weeks from first commit to live product
  • 4 music generation APIs evaluated
  • 2 LLM models in sequence for lyrics
  • 3 real security and reliability issues caught pre-launch
  • Full Shopify payments integration with HMAC verification
  • Personal user cabinet with order history and audio playback
  • Provider-agnostic music pipeline — swap API without rewrite
Architecture decisions

What made it work

  • Two-model lyrics pipeline: creativity and structure as separate concerns
  • OpenRouter as LLM gateway: model-agnostic, one API key
  • Idempotent webhook processing: unique constraint on Shopify order ID
  • SSRF-safe audio proxy: hostname whitelist, HTTPS-only
  • Status tracking on every order: no silent failures
  • Provider-agnostic music API layer: all four registered, one active
Tech stack

Tools used

Next.js 14 TypeScript PostgreSQL Suno V5.5 Gemini 2.5 Flash Claude Sonnet 4.6 OpenRouter Shopify Resend VPS Frankfurt GitHub Actions CI/CD VS Code + Claude Code
FAQ

Common questions about building an AI music SaaS

Why use two different LLMs for lyrics instead of one?
A single model couldn't do both jobs well. Gemini 2.5 Flash at high temperature (0.8) writes vivid, emotionally raw Polish lyrics but ignores song structure. Claude Sonnet 4.6 at low temperature (0.35) then edits that draft into a strict [Verse]/[Chorus]/[Bridge] format with correct rhyme scheme — the structure Suno's music engine needs to generate a coherent song. High temperature alone breaks structure; low temperature alone kills the creativity.
Why was Suno V5.5 chosen over ElevenLabs, Udio, or fal.ai/Minimax?
All four were tested against the same brief before shipping. fal.ai/Minimax had weak Polish phonetics on vowel-heavy words. ElevenLabs Music had good vocal timbre but no awareness of verse/chorus structure. Udio showed promising quality but failed silently during testing. Only Suno V5.5 combined natural Polish vocals with correct interpretation of the [Verse]/[Chorus] tags — and the architecture keeps all four as registered providers, so switching is a config change, not a rewrite.
What was the SSRF vulnerability in the audio proxy, and how was it fixed?
Suno's CDN URLs expire within hours, so a proxy-audio route was built to re-serve audio on demand. The first version accepted any URL as input — a classic server-side request forgery hole. The fix restricted it to strict hostname validation, allowing only *.suno.ai over HTTPS, with a backward-compatible allowlist entry for legacy fal.ai URLs already stored in the database. Lesson: never trust a user-supplied URL in a server-side fetch without an allowlist.
How is it possible to ship a full AI SaaS in two weeks with no prior music-AI experience?
By testing the riskiest unknowns first — four music-generation APIs were benchmarked before writing any production code, which surfaced the Suno decision early. The rest, the lyrics pipeline, Shopify billing, webhook idempotency, reused known patterns. Three real issues still surfaced before launch — a Shopify test-mode gotcha, the SSRF hole, and duplicate webhook delivery — all caught and fixed pre-launch, not in production.
Need a custom AI product built fast?

I build full-stack AI applications from scratch: music generators, content pipelines, automation tools, SaaS products. Two weeks from brief to live. Based in Munich, working with clients across Europe.

← Back to articles