Just Drink

Just Drink was created as the next stage of the existing DinLokaleBodega system: a platform that already had a mobile application, CMS, drink packages, subscriptions, and participating venues. Users could purchase a package or subscription through the app and redeem it in partner venues, while the administration team managed the core parts of the system through the CMS.

That means this project did not begin as mobile app development from scratch, with a product that still needed to validate its basic idea. The starting point was different: the product already had a working core, but it needed clearer positioning, a better explanation for users, and enough structure to support broader day-to-day use by venues, users, and administrators.

The task was not to build yet another app for buying drinks through subscriptions or one-off packages. The goal was to turn an existing product into a clearer digital platform: one that users could understand quickly, venues could recognize as useful for their visibility, and administrators could manage without unnecessary manual reconciliation.

The project covered several connected areas:

• rebranding DinLokaleBodega into Just Drink
• building a new website that explains the service more clearly to users and venues
• improving and modernizing the mobile application
• developing Vandrepokalen, a monthly venue ranking connected to donations
• introducing 6-Pack and a more flexible Klippekort as clearer one-off purchase models
• expanding the CMS for products, venues, donations, and monthly cycles
• strengthening the technical foundation with Flutter, Hasura, Qwik, and a TypeScript API
• preparing the system for future settlement cycles, documents, and partner payouts

From a business perspective, Just Drink needed to achieve three important goals: explain the value of the service more clearly, give users a reason to return to the app, and give administrators control over an increasingly complex system of offers, venues, purchases, and donations.

DinLokaleBodega as the Foundation for the Just Drink Platform

DinLokaleBodega was not just an idea for an app or an early concept waiting to become a product. The system was already in use and had a clear functional foundation: users could buy drink packages, redeem them in venues, and the client could manage the offer and basic platform settings through the CMS.

For that reason, the project could not be treated as a new app build from zero. The first step was to understand what already worked well in the existing product, and only then decide what needed to change. It was more important to identify which parts of the system were worth keeping and which parts needed to be reshaped for the next stage of the product.

Just Drink needed to explain the service better, present the offer more clearly, give people a reason to open the app more often, and allow administrators to manage a more complex system of venues, packages, donations, and monthly cycles without unnecessary manual work.

The existing system did not need to be replaced. It needed to be reorganized so that it would remain simple for users while gaining enough structure in the background to support further growth.

What Needed to Change in the Just Drink System

The first challenge was how the service was explained. The name, website, and overall presentation needed to immediately show what the app offered: where users could find a venue, what they could buy, and how they could use a purchased package when going out. With this type of service, the first impression cannot depend on extra explanation.

The second challenge was the usage habit around the app. If users open the app only when they are buying or redeeming a package, the product remains tied to one short moment. That may be enough for a basic purchase flow, but it is not enough for a product that wants to build a more active relationship with users and venues.

Just Drink therefore needed content that would naturally change over time. Not a disconnected add-on, but a feature built on top of existing user behavior. This became Vandrepokalen: a monthly venue ranking connected to donations.

Vandrepokalen introduces gamification with a charitable purpose. Purchases and subscription renewals contribute to the monthly ranking, while the collected amount is directed toward a charitable cause. This gives the app an additional layer of meaning: users are still buying drinks, but their choice now has a visible continuation through the venue, the ranking, and the donation goal.

The offer itself also needed to be made clearer. Some users simply want to try the app without subscribing. Others already know where they want to use the benefits and want more flexibility when purchasing. A single offer cannot serve both situations equally well, which is why 6-Pack and the more flexible Klippekort became important parts of the new Just Drink system.

Finally, all of this needed proper administration behind it. In business system and web application development , a change rarely affects only what the user sees in the app. If new products, donations, venue rankings, and monthly rules are introduced, the CMS must be able to support the whole system without constant manual coordination.

Before this new stage, the system had several limitations:

• the name was strongly tied to the initial local context
• the app was mainly connected to buying and redeeming packages
• the offer did not serve new and returning users equally well
• donations and monthly venue rankings were not part of the user experience
• the CMS needed to be expanded for more complex day-to-day operations

After development, Just Drink gained a clearer foundation:

• a name and website that explain the service faster
• a mobile app with Vandrepokalen and donations
• a simpler entry point through 6-Pack
• a more flexible Klippekort
• a CMS for managing products, venues, donations, and monthly cycles
• optimized card payments through Stripe

Website, Mobile App, and CMS as Connected Parts of One Business System

For Just Drink, improving only one part of the product would not have been enough. A new website would have limited impact if users did not get a clear app experience after downloading it. In the same way, new app features would not make sense if the client and its partners could not manage them independently through the CMS.

The project was therefore shaped as a connected whole: a business system where each part has a specific role. Users see the website and the app. Venues see their presence in the offer and the ranking. The client needs a system behind the scenes that can be updated and managed every day.

In business system and web application development , this connection is critical: anything shown to the user must have clean administration behind it. If a product, venue, donation goal, or monthly cycle changes, that change needs a clear place in the system and must be reflected consistently in the user experience.

A Website That Explains the Service to Users and Venues

The website is the first point of contact for users and venues. Its job was not only to present the new name, but to quickly explain what Just Drink is, how it works, which offers are available, and why it makes sense for venues to participate.

That is why website development in this project was not just about creating a new presentation page. The website needed to do what users expect in the first few seconds: explain what Just Drink is, who it is for, and why they should download the app.

This part of the system was built with Qwik because the website needed to be fast, easy to scan, and well prepared for organic visibility. In Just Drink, the website is not just a brand introduction. It is the first layer that explains the service to users and venues before they even reach the app.

The role of the website is especially important because the product has two audiences. Users need to quickly understand how to get drink packages and where they can use them. Venues need to see why participating in the system has value through visibility, ranking, and connection to donation cycles.

Android and iOS Mobile App with Backend and CMS

The mobile app remains the central place where Just Drink is used. In the app, users buy packages, redeem them in venues, follow Vandrepokalen, view donations, and manage the venue they are contributing to.

Mobile app development in a project like this cannot be reduced to building screens. It requires understanding what users do before a purchase, what they need to see at the moment of purchase, and what brings them back to the app later.

In Just Drink, that return path is connected to Vandrepokalen and donations. The app displays the monthly venue ranking, collected amounts, and the user’s personal contribution. As a result, users do not open the app only when they want to buy or redeem a package. They also open it to check the result, follow their venue, and see how the donation goal is developing during the month.

The app was developed in Flutter as a cross-platform mobile application for Android and iOS. This approach enables a consistent user experience on both platforms and simplifies the maintenance of features that must work the same way for all users.

CMS for Managing Mobile App Content

The CMS is the third part of the same system. Without it, the website and app would quickly become difficult to maintain, because every change in the offer, venues, donation goals, rankings, or monthly cycles needs a place where it can be managed.

The CMS is not a secondary administrative add-on. It controls what users see in the app: products, venues, donation months, rules, rankings, and donation overviews. Since the platform includes multiple venues and partners, the CMS was set up as the operational center for day-to-day management of a multivendor system.

Behind the CMS and the app are Hasura and an API written in TypeScript. Hasura enables structured data access, while the TypeScript API handles business rules that should not be scattered across the website, mobile app, and administration.

This makes Just Drink closer to a complex system build than to a simple app with a few screens. The website, mobile app, and CMS work together: one part explains the service, another carries it to the user, and the third makes it possible to manage the whole system day by day.

Features That Changed How the Mobile App Is Used

The biggest change in the Just Drink app was Vandrepokalen. Other features either connect to it or make the offer around existing drink package purchases clearer.

Vandrepokalen: A Monthly Venue Ranking Connected to Donations

Vandrepokalen is the central new feature of Just Drink. It gives the app content that changes from month to month and introduces something users can follow even when they are not immediately buying a new package.

It is a monthly venue ranking connected to donations. Purchases and subscription renewals contribute to the donation part of the system, and venues are ranked based on the contribution generated through them. In the app, users can see the current ranking, the amount collected, and the cause being supported.

This changes the way the app lives. Previously, the main reason to open the app was buying or redeeming a package. With Vandrepokalen, users have an additional reason: they can check how their venue is doing, how much has been collected, and whether the ranking is changing during the month.

It is important that users do not have to learn a completely new way of using the app. They still buy a package and redeem it in a venue. The difference is that their purchase now has a visible continuation: it connects to a venue, a ranking, and a donation.

For venues, Vandrepokalen also changes their role in the app. A venue is no longer only a place where a package can be redeemed. It becomes a participant in a monthly ranking and part of a donation cycle.

Related Vandrepokalen Features

Vandrepokalen is not just a list of venues. To make the ranking understandable for users and reliable enough for administration, it needs several connected features.

My Donations

Users can see which venue they currently support, review donation history, amounts, and dates, and change the venue they want to contribute to. The donation is therefore not hidden in the background of a purchase. Users have visibility and control over their contribution.

Monthly Cycles

Vandrepokalen runs on monthly cycles. There is a current month, previous months, and a history of results. At the end of each month, the result is locked so the ranking remains credible and can be reviewed later.

CMS Donation Overview

Administration can use the CMS to see how the donation result was created. The venue-level overview shows which purchases and subscription renewals contributed to the result and which venue they were connected to. This is important for control, transparency, and later reporting.

A Clearer Offer for Different User Types

Alongside Vandrepokalen, the offer itself needed to be refined. Not all Just Drink users behave in the same way. Some want to try the app first, while others already know where they want to go out and want more freedom when buying.

6-Pack

6-Pack is a simpler entry point for users who do not want to subscribe immediately. A user buys six drinks for 55 DKK, the package is valid for 30 days, and it can be used for a maximum of one drink per day. This lets users try the service without a long-term commitment, while still spreading usage across multiple days.

Klippekort

Klippekort is an improved 10-drink package for users who want more flexibility. Users can buy multiple packages at once, buy multiple packages for the same venue, and manage them separately. Each package has its own balance and validity period, making it easier to track what has been purchased and how much remains available.

This offer structure matters because it reduces friction when entering the app. A new user can start with the simpler package, while a user who already knows how they want to use Just Drink gets more freedom through Klippekort.

Planned Upgrades: Settlements, Documents, and Partner Payouts

Just Drink is now structured for further development. When a system connects users, venues, purchases, subscriptions, and donations, the natural next step is the financial layer: settlements, documents, and payouts to venues.

While the number of venues and transactions is smaller, some checks can still be handled manually. But as the system grows, manual settlements, spreadsheets, and follow-up reconciliation can become a bottleneck. That is why it is important that purchase, subscription, donation, and venue data is already connected and governed by clear rules.

Further development of the system is planned to include:

• settlement cycles
• preparation of SEPA XML files for venue payouts
• self-billing invoices for venues
• commission invoices for platform revenue
• CSV summaries for review
• an audit log of important actions
• document delivery to venues

Locked data will be the most important part of the process. If a settlement is being prepared for a specific period, it must be clear which purchases are included, which venue they belong to, and which amounts are being processed. This naturally follows the logic of Vandrepokalen, where a completed month must have a credible final result.

SEPA XML files remove the need to prepare payout orders manually. As the number of venues grows, every manual step becomes slower and more prone to error. The system can therefore prepare a payment file based on data that has already been checked and locked.

Documentation is equally important. Self-billing invoices give venues the documents they need for their records, while the platform commission is handled separately. This clearly separates what belongs to the venue from what belongs to the platform.

CSV summaries and control records help administrators review what entered a settlement, which amounts were prepared, and whether the data remained consistent from the moment it was locked to the moment documents were generated. In financial processes, it is not enough to know the final number. It is also important to know how that number was created.

That is why the audit log matters as well. If a document is generated, a settlement status changes, a file is downloaded, or documents are sent to venues, that action should remain recorded. This gives administration better control and reduces uncertainty in later reviews.

Result Summary: A Mobile App, CMS, and Business System That Are Easier to Manage

Just Drink became a clearer version of a system that already had a functional foundation. Instead of discarding the existing product, the parts that worked were kept, and the website, mobile app, and CMS were connected into a system that gives users, venues, and administration clearer roles.

For users, the service became easier to understand from the first touchpoint. Users can more quickly see what Just Drink offers, how to get drink packages, and where they can use them. With 6-Pack they get a simpler first step, while Vandrepokalen and donation overviews give them a reason to return to the app even outside the moment of purchase.

For venues, the app is no longer only a place where a package can be redeemed. Through Vandrepokalen, venues gain a more visible role, enter a monthly ranking, and become part of a donation cycle. This means the app is not limited to the relationship between user and offer; it also includes the venue, the community, and a concrete monthly result.

For administration, the client gets a system that is easier to manage. The CMS covers products, venues, donation goals, monthly cycles, rankings, and donation overviews. This reduces the need for manual reconciliation and opens the path toward further development of settlements, documents, and payouts.

Technically, this control does not come from one tool alone. It comes from the combination of the Flutter mobile app, Qwik website, Hasura data layer, and TypeScript API. Each part has its own role, but the value appears when they work as one connected system.

The result is a product that feels simpler to users while giving the client more control over what happens in the background. Just Drink is structured so that the user experience stays simple, while the system behind it is organized enough to support venues, purchases, donations, monthly results, and administrative processes.

This project shows that the development of more complex digital products does not end with the user interface. A website that explains the service clearly, a CMS that keeps the system under control, and structured data that allows the product to grow without losing order are just as important.

If you have an app, web platform, or internal system that no longer matches the way your business actually works, the first step does not always have to be a complete rebuild. Often, it is more important to assess what already works, where users or administrators are struggling, and where the system needs a clearer structure.

We solve these kinds of projects through business system and web application development , depending on whether an existing product needs to be improved, expanded, or placed on a stronger technical foundation.