Forbes

    Case study · Partymaker Group

    A complete events and ticketing app, from discovery to the door

    Find a night out, buy the ticket, get scanned at the door. We built all three, plus the organizer admin behind them, on iOS, Android and web.

    Live · iOS, Android, web

    Client
    Partymaker Group
    Sector
    Events & entertainment
    Delivery
    B2L. studio
    Platforms
    iOS · Android · web
    Languages
    SK · CZ · EN · DE
    In stores since
    August 2026
    partymaker.euApp StoreGoogle Play
    Partymaker home feed listing tonight's and upcoming events
    Challenge
    The group sold through external ticketing portals, so it rented the checkout and the customer relationship with it.
    Built
    Guest apps on iOS, Android and web, the organizer admin behind them, and a check-in system for the door.
    Outcome
    Live in both stores since August 2026, in four languages, with a ticket that proves itself from its own signature.
    Working with Elevon.io, we didn't just build an app, we built a complete ecosystem for nightlife. They understood our vision and turned it into reality through AI Native development.
    Martin PetrusFounder & CEO, Partymaker Group a.s.

    The product

    Three surfaces, one product

    Guests discover and buy. Organizers publish and track. Door staff scan. Each surface is built for its own job and reads from the same catalog, so a ticket sold in the browser is the ticket scanned at the door.

    Screens from the released app. Slovak interface, one of the four languages it ships in.

    Filter panel covering eleven event types

    Filters across eleven event types1 of 7

    Screens

    Filter panel covering eleven event types

    How it fits together

    One backend, five clients

    A feature is built once and appears everywhere, because all five clients share the same data model and the same logic.

    Core

    Shared backend

    One catalog, one ticket model, one set of rules

    • iOS app

      App Store

    • Android app

      Google Play

    • Web

      partymaker.eu

    • Organizer admin

      Events, promoters, venues

    • Door scanners

      Parallel stations

    Every client reads and writes the same catalog. Feature parity across iOS, Android and web is a property of this arrangement, not a separate effort.
    How the ticket validates
    Every QR code carries an HMAC signature, so its validity is verified from the signature itself, with no lookup into the database. The same code works in the app, in Apple Wallet, in Google Wallet and in the PDF that arrives by email, printed on paper included. Several scanning stations run in parallel with hardware readers deployed on site, sized for roughly 1,000 arriving guests.
    Where the events come from
    An aggregation layer maps public event data from three external Slovak ticketing sources into a single model, deduplicated and categorized on import. Admins then curate what was imported: show, hide, feature, assign a category and a venue. The catalog holds one shape no matter where an event came from.
    Covers, languages and accessibility
    Event covers arrive in every aspect ratio and quality, and the copy runs in four languages. A 3:4 cover system with tokens, breakpoints, blur fill for landscape sources, a sold-out treatment and an admin crop holds the layout without a designer touching a single event. The apps ship with an age gate at sixteen, WCAG AA contrast, 44pt targets, screen reader support and 200 percent font scaling.

    How it was delivered

    Milestone by milestone

    The platform was built in stages rather than one release. Each stage went into real use before the next one started, so the client kept control of scope and a pause never left a half-finished product.

    1. 01

      App and admin base

      The catalog, the app shell and the organizer admin.

    2. 02

      Checkout and the digital ticket

      Own checkout, card, Apple Pay and Google Pay, ticket in the wallet.

    3. 03

      Personalization and check-in

      The For you section, and the signed QR validated at the door.

    4. 04

      Event aggregation

      Three external sources normalized into one catalog.

    5. 05

      Sales on the group's own account

      The last dependency on an external portal removed.

    Every milestone had to stand on its own in production. That is a harder brief than one big launch, and it is the reason nothing was ever half-built and unusable.

    Where it stands today

    Delivered and running

    This is an ongoing engagement. Below is what is delivered and running today, without commercial figures.

    • Public app in the App Store and on Google Play, iOS and Android
    • Own sales channel on own platform, web at partymaker.eu, in four languages
    • Event aggregation in production across three external sources, normalized into one catalog
    • Tickets verifiable from the signature alone, hardware readers deployed on site
    • A documented cover and listing design system, so new events need no design work
    • Platform milestones delivered and accepted one at a time, each in use before the next began
    Why it worked
    The hardest constraint was named at the start rather than discovered late. We knew from the first milestone that the sources would never agree on a format, so the data layer was designed for that instead of being rewritten halfway through. Building the cover system as a system, not per event, is what makes the product scale.

    Have a product worth building?

    We scope it in milestones, so each one goes live and gets used before the next one starts.

    Start a conversation
    Contact us

    We use essential and analytics cookies by default to ensure proper functionality and understand site usage. Marketing cookies are off unless you opt in. Privacy Policy