SIPPER

SIPPER is a Danish cocktail-recipe product built around a simple question: what can I make with the ingredients I already have? It combines structured recipes with personal features such as saved recipes, ratings, notes, and a digital drinks cabinet that matches a user’s ingredients with available cocktails.

The product began as a smaller collaboration and has since been substantially rebuilt and repositioned. I now own and develop the entire product, including its branding, UX, data model, content workflow, authentication, and technical architecture.

Project overview

SIPPER helps people find approachable cocktail recipes and make better use of the bottles and ingredients already in their homes. Visitors can browse recipes, while registered users can create a more personal experience by saving favourites, rating recipes, adding notes, and maintaining a digital overview of their drinks cabinet.

The cabinet is the feature that turns SIPPER from a conventional recipe site into a utility. Users select the ingredients they have, and the product compares that inventory with the requirements of each recipe. This makes it possible to discover drinks that can be made immediately rather than browsing recipes that require an entirely new shopping list.

The live product is Danish-language, while this case study is also available in English to explain the work to international hiring teams.

Context and my responsibility

The first version was created with two UX collaborators under the name Cocktailskassen. I was responsible for development, while we worked together on the initial concept and user experience. After the first release, I took over full ownership of the product and continued it independently.

In 2024, I rebranded Cocktailskassen as SIPPER and redesigned the experience based on user feedback. The goal was to make the identity more focused, the navigation clearer, and the content easier to explore. Since then, I have replaced the original Hugo static site with a full product architecture based on Next.js, Supabase, and Sanity.

I now handle product direction, branding, UX, frontend and backend development, authentication, data modelling, deployment, and content operations. I use AI as an editorial aid when developing recipe content, while retaining responsibility for the structure, validation, presentation, and quality of what is published.

The problem

Most cocktail websites are designed as large inspiration catalogues. They are useful when a user already knows what to search for, but less useful when the actual question is practical: “What can I make without buying several new ingredients?”

Cocktail recipes also contain more structure than a normal article. Ingredients have quantities and roles, recipes belong to categories, preparation time and difficulty affect the decision, and users may want to record their own experience. Treating every recipe as a flat page would make filtering, matching, and personalisation difficult.

The product therefore needed to solve two related problems:

• Make recipes clear and approachable for people who are not experienced mixologists.
• Turn recipe and ingredient data into a useful personal tool rather than only a collection of articles.

Requirements and constraints

SIPPER needed a content workflow that made it practical to maintain recipes and editorial material without editing application code. At the same time, personal data such as saved recipes, ratings, notes, and cabinet contents had to be connected securely to authenticated users.

The main requirements were:

• Structured and reusable recipe and ingredient content.
• Searchable and filterable recipe discovery.
• User accounts with private, persistent data.
• A cabinet feature that could compare available ingredients with recipe requirements.
• A visual identity that felt more refined and broadly accessible than the original project.
• A content system that supported ongoing editorial work.
• Validation at the boundaries between forms, application logic, and stored data.

Because the site is currently Danish-only, the language and tone also needed to feel natural to a Danish audience rather than translated from an international recipe template.

Product and UX decisions

I designed SIPPER around progressive value. A visitor can use the recipe catalogue without creating an account. Registration becomes relevant when the user wants the product to remember preferences and ingredients.

Recipe pages prioritise the information needed while making a drink: ingredients, quantities, preparation steps, difficulty, and time. The structure is intentionally scannable, because the product is often used in a kitchen or social setting rather than read as a long article.

Saved recipes, ratings, and notes support repeated use. A rating records the user’s reaction, while notes can capture adjustments such as preferred ratios or substitutions. These features recognise that cocktail recipes are often adapted after the first attempt.

The digital cabinet provides a second way into the content. Instead of starting with a recipe name, the user starts with available ingredients. The product then identifies recipes whose requirements match the cabinet, making discovery more practical and personalised.

The rebrand from Cocktailskassen to SIPPER was also a product decision. The former identity was closely tied to the original project and a narrower presentation. SIPPER gave me room to create a cleaner visual system and position the product as an ongoing platform rather than a one-off recipe collection.

Technical implementation

The current application is built with Next.js. Supabase handles authentication and personal application data, including user-specific interactions such as saved recipes, ratings, notes, and cabinet contents.

Sanity is the content source for recipes and editorial material. Separating managed content from personal user data gives each system a clear responsibility. Recipes can be edited through a dedicated content workflow, while Supabase manages state that belongs to an authenticated user.

This division was an important improvement over the earlier Hugo implementation. The static version was effective for publishing pages, but it became increasingly limiting as SIPPER moved toward accounts, personal data, and interactive matching. Rebuilding the product allowed the architecture to reflect what SIPPER had become rather than preserving assumptions from its first version.

Zod is used to validate data where it enters the application. This is especially relevant for forms and user-generated state, where the interface and database need to agree about accepted values. Tailwind CSS supports a consistent responsive design system across recipe browsing, account features, and content pages.

The recipe data model is central to the product. Ingredients must be reusable across several recipes, while each recipe still needs its own quantity and preparation context. That structure supports the cabinet comparison and makes it possible to build filtering and discovery features without duplicating ingredient information across unrelated pages.

Communication and collaboration

The original collaboration taught me to distinguish between UX intentions and implementation details. The two UX designers could focus on user needs, layout, and testing, while I translated those decisions into technical components and content structures.

After taking sole ownership, I continued to use feedback as a product input. During the rebrand, I had to decide which parts of the existing experience users valued and which parts were limiting the product. Communicating changes clearly mattered because an established name and interface had already built recognition.

SIPPER also requires me to communicate technical decisions through the product itself. Users should not need to understand databases or matching logic to know why a recipe is available from their cabinet. The interface has to turn structured data into an explanation that feels obvious.

Results and current status

SIPPER is live as a Danish recipe product with a growing content library, user accounts, personal recipe tools, and the drinks-cabinet feature. The current public catalogue contains more than thirty recipes, supported by ingredient pages and editorial content.

The most significant result is the product’s transformation. It has moved from a static recipe site into an application with managed content, authentication, personal state, and ingredient-based discovery. This gives the project a clearer long-term direction and makes future features possible without another fundamental rebuild.

I do not currently present usage metrics because I do not yet have a reliable dataset that would add meaningful context. The next stage is therefore focused on improving the content library, observing how users interact with the cabinet, and building an evidence base for further product decisions.

Lessons and retrospective

The project showed me that a successful rebuild requires more than replacing one framework with another. The important question was not whether Next.js was more modern than Hugo, but whether the architecture matched the product’s new responsibilities.

I also learned that structured content creates product opportunities. Once recipes and ingredients are modelled consistently, the same data can support browsing, filters, cabinet matching, ingredient libraries, and future recommendations. Content modelling therefore became part of the product design rather than only a backend concern.

If I were beginning again, I would define the distinction between editorial recipe data and personal user data from the start. The earlier static architecture was appropriate for the original scope, but the later transition required rethinking both the content model and the user experience.

What this project demonstrates

SIPPER demonstrates my ability to take an existing concept, reassess its positioning, and rebuild it as a more coherent product. It shows full-stack development, content modelling, authentication, personalisation, branding, and my ability to translate feedback from designers and users into a maintainable technical direction.