SIPPER

SIPPER er et dansk cocktailprodukt bygget omkring et enkelt spørgsmål: Hvad kan jeg lave med de ingredienser, jeg allerede har? Det kombinerer strukturerede opskrifter med personlige features som gemte opskrifter, ratings, noter og et digitalt barskab, der matcher brugerens ingredienser med relevante cocktails.

Produktet begyndte som et mindre samarbejde og er siden blevet væsentligt ombygget og repositioneret. Jeg ejer og udvikler nu hele produktet, herunder branding, UX, datamodel, content workflow, authentication og teknisk arkitektur.

Projektet kort fortalt

SIPPER hjælper brugere med at finde overskuelige cocktailopskrifter og få mere ud af de flasker og ingredienser, de allerede har derhjemme. Besøgende kan browse opskrifter, mens registrerede brugere kan skabe en mere personlig oplevelse ved at gemme favoritter, rate opskrifter, tilføje noter og holde et digitalt overblik over deres barskab.

Barskabet er den feature, der gør SIPPER til mere end et traditionelt opskriftssite. Brugeren vælger sine ingredienser, hvorefter produktet sammenligner lageret med kravene i de enkelte opskrifter. Det gør det muligt at opdage drinks, der kan laves med det samme, frem for at browse opskrifter, som kræver en helt ny indkøbsliste.

Det live produkt er dansksproget, mens denne case også findes på engelsk, så arbejdet kan præsenteres for internationale hiring teams.

Kontekst og mit ansvar

Den første version blev udviklet sammen med to UX-samarbejdspartnere under navnet Cocktailskassen. Jeg havde ansvaret for udviklingen, mens vi samarbejdede om det oprindelige koncept og den første brugeroplevelse. Efter den første lancering overtog jeg det fulde ejerskab og fortsatte projektet selvstændigt.

I 2024 rebrandede jeg Cocktailskassen til SIPPER og redesignede oplevelsen på baggrund af brugerfeedback. Målet var at gøre identiteten mere fokuseret, navigationen tydeligere og indholdet lettere at udforske. Siden har jeg erstattet det oprindelige statiske Hugo-site med en egentlig produktarkitektur baseret på Next.js, Supabase og Sanity.

Jeg står nu for produktretning, branding, UX, frontend- og backendudvikling, authentication, datamodellering, deployment og content operations. Jeg bruger AI som redaktionelt værktøj i arbejdet med opskriftsindhold, men har selv ansvaret for struktur, validering, præsentation og kvaliteten af det publicerede materiale.

Problemet

De fleste cocktailsites fungerer som store inspirationskataloger. De er nyttige, når brugeren allerede ved, hvad der skal søges efter, men mindre nyttige, når spørgsmålet er praktisk: “Hvad kan jeg lave uden først at købe en række nye ingredienser?”

Cocktailopskrifter indeholder samtidig mere struktur end en normal artikel. Ingredienser har mængder og funktioner, opskrifter tilhører kategorier, tid og sværhedsgrad påvirker valget, og brugere kan have behov for at gemme deres egne erfaringer. Hvis hver opskrift blot blev behandlet som en flad side, ville filtrering, matching og personalisering blive unødigt vanskeligt.

Produktet skulle derfor løse to relaterede problemer:

• Gøre opskrifter tydelige og tilgængelige for personer, der ikke er erfarne mixologists.
• Omsætte opskrifts- og ingrediensdata til et personligt værktøj frem for kun en samling artikler.

Krav og begrænsninger

SIPPER havde brug for et content workflow, der gjorde det praktisk at vedligeholde opskrifter og redaktionelt materiale uden at redigere applikationskode. Samtidig skulle personlige data som gemte opskrifter, ratings, noter og barskabsindhold forbindes sikkert til authenticated users.

De vigtigste krav var:

• Struktureret og genanvendeligt opskrifts- og ingrediensindhold.
• Søgbar og filtrerbar recipe discovery.
• Brugerprofiler med private og persistente data.
• En barskabsfeature, der kunne sammenligne tilgængelige ingredienser med opskriftskrav.
• En visuel identitet, der var mere raffineret og bredt tilgængelig end det oprindelige projekt.
• Et contentsystem, der understøttede løbende redaktionelt arbejde.
• Validering ved grænserne mellem forms, applikationslogik og lagrede data.

Fordi produktet i øjeblikket kun er på dansk, skulle sprog og tone desuden føles naturligt dansk frem for oversat fra en international opskriftsskabelon.

Produkt- og UX-beslutninger

Jeg designede SIPPER omkring progressiv værdi. En besøgende kan bruge opskriftskataloget uden at oprette en profil. Registration bliver relevant, når brugeren ønsker, at produktet skal huske præferencer og ingredienser.

Opskriftssider prioriterer den information, der er nødvendig under tilberedningen: ingredienser, mængder, fremgangsmåde, sværhedsgrad og tid. Strukturen er bevidst scannable, fordi produktet ofte bruges i et køkken eller en social situation og ikke læses som en lang artikel.

Gemte opskrifter, ratings og noter understøtter gentagen brug. En rating registrerer brugerens vurdering, mens noter kan gemme justeringer som foretrukne blandingsforhold eller substitutionsmuligheder. De features tager højde for, at cocktailopskrifter ofte bliver tilpasset efter første forsøg.

Det digitale barskab giver en anden indgang til indholdet. I stedet for at begynde med navnet på en drink begynder brugeren med sine tilgængelige ingredienser. Produktet identificerer derefter opskrifter, hvis krav matcher barskabet, og gør discovery mere praktisk og personlig.

Rebrandingen fra Cocktailskassen til SIPPER var også en produktbeslutning. Den tidligere identitet var tæt knyttet til projektets første form og en smallere præsentation. SIPPER gav plads til et renere visuelt system og til at positionere produktet som en løbende platform frem for en enkeltstående opskriftssamling.

Teknisk implementering

Den nuværende applikation er bygget med Next.js. Supabase håndterer authentication og personlige applikationsdata, herunder brugerrelaterede interaktioner som gemte opskrifter, ratings, noter og barskabsindhold.

Sanity er content source for opskrifter og redaktionelt materiale. Ved at adskille managed content fra personlige brugerdata får hvert system et tydeligt ansvar. Opskrifter kan redigeres gennem et dedikeret content workflow, mens Supabase håndterer state, der tilhører en authenticated user.

Denne opdeling var en væsentlig forbedring i forhold til den tidligere Hugo-implementering. Den statiske version fungerede godt til publicering af sider, men blev stadig mere begrænsende, efterhånden som SIPPER bevægede sig mod profiler, personlige data og interaktiv matching. Ombygningen gjorde det muligt at lade arkitekturen afspejle det produkt, SIPPER var blevet, frem for at bevare antagelserne fra den første version.

Zod bruges til at validere data, når de kommer ind i applikationen. Det er særligt relevant for forms og user-generated state, hvor interface og database skal være enige om accepterede værdier. Tailwind CSS understøtter et konsistent responsivt designsystem på tværs af opskriftsvisning, profilfeatures og contentsider.

Opskrifternes datamodel er central for produktet. Ingredienser skal kunne genbruges på tværs af flere opskrifter, mens hver opskrift fortsat har sin egen mængde og tilberedningskontekst. Strukturen understøtter barskabsmatchingen og gør det muligt at udvikle filtre og discovery-features uden at duplikere ingrediensinformation på tværs af ellers uafhængige sider.

Kommunikation og samarbejde

Det oprindelige samarbejde lærte mig at skelne mellem UX-intentioner og implementeringsdetaljer. De to UX-designere kunne fokusere på brugerbehov, layout og tests, mens jeg oversatte beslutningerne til tekniske komponenter og contentstrukturer.

Efter at have overtaget hele produktet fortsatte jeg med at bruge feedback som produktinput. Under rebrandingen skulle jeg vurdere, hvilke dele af den eksisterende oplevelse brugerne satte pris på, og hvilke dele der begrænsede produktet. Tydelig kommunikation om ændringerne var vigtig, fordi det tidligere navn og interface allerede havde opbygget genkendelse.

SIPPER kræver også, at tekniske beslutninger kommunikeres gennem selve produktet. Brugeren skal ikke forstå databaser eller matchinglogik for at vide, hvorfor en opskrift kan laves ud fra barskabet. Interfacet skal omsætte strukturerede data til en forklaring, der føles indlysende.

Resultater og nuværende status

SIPPER er live som et dansk opskriftsprodukt med et voksende content library, brugerprofiler, personlige opskriftsværktøjer og barskabsfeaturen. Det offentlige katalog indeholder aktuelt mere end 30 opskrifter, understøttet af ingredienssider og redaktionelt indhold.

Det vigtigste resultat er produktets transformation. Det er gået fra et statisk opskriftssite til en applikation med managed content, authentication, personlig state og ingrediensbaseret discovery. Det giver projektet en tydeligere langsigtet retning og gør fremtidige features mulige uden endnu en grundlæggende ombygning.

Jeg viser ikke brugstal på nuværende tidspunkt, fordi jeg endnu ikke har et stabilt datasæt, der giver meningsfuld kontekst. Næste fase fokuserer derfor på at udbygge indholdsbiblioteket, observere hvordan barskabet bliver brugt og skabe et bedre datagrundlag for videre produktbeslutninger.

Læring og retrospektiv

Projektet viste mig, at en vellykket ombygning kræver mere end at udskifte ét framework med et andet. Det afgørende spørgsmål var ikke, om Next.js var mere moderne end Hugo, men om arkitekturen passede til produktets nye ansvar.

Jeg lærte også, at struktureret content skaber produktmuligheder. Når opskrifter og ingredienser bliver modelleret konsistent, kan de samme data understøtte browsing, filtre, barskabsmatching, ingrediensbiblioteker og fremtidige anbefalinger. Content modelling blev derfor en del af produktdesignet og ikke kun et backend-anliggende.

Hvis jeg begyndte forfra, ville jeg definere skellet mellem redaktionelle opskriftsdata og personlige brugerdata fra starten. Den tidligere statiske arkitektur var passende til det oprindelige scope, men den senere transition krævede, at både content model og brugeroplevelse blev gentænkt.

Hvad projektet viser

SIPPER viser, at jeg kan overtage et eksisterende koncept, revurdere dets positionering og genopbygge det som et mere sammenhængende produkt. Projektet demonstrerer full-stack udvikling, content modelling, authentication, personalisering, branding og min evne til at omsætte feedback fra designere og brugere til en vedligeholdelig teknisk retning.