A mobile marketplace for faster venue service
Crowded nightlife venues create the same problem for guests and staff: demand arrives in bursts. People wait to order, bartenders face an uneven queue, and a venue has few tools for offering a faster service option without creating more confusion at the bar.
SipSkip is a mobile platform that lets participating venues offer paid priority passes. Guests discover an approved venue, choose the available pass, complete payment, and present a clear redemption screen to staff. Venue managers control the public offer, while the platform coordinates purchase state, redemption, and the records needed to run the service.
Priority Soft helped turn the idea into a mobile marketplace. We defined the consumer and venue flows, built the Flutter apps and Django service layer, and integrated payments and subscriptions. Feedback from real use then changed how the product packaged its offer.
Designing both sides of the exchange
SipSkip serves guests, venue teams, and platform administrators. Guests need speed during a night out. Venues control availability, staff, redemptions, and public listings. Administrators verify venues and oversee pass state.
We mapped each role before designing screens. Guests browse cities and venues, purchase a pass, and review active or past passes. Venue managers apply to the platform, configure offers, invite staff, and review activity. Administrators approve participation and use controls that remain outside public accounts.
The product uses one shared foundation with separate permissions for each role. Guests cannot change venue settings, and bartenders receive limited service access. Creating an ordinary account does not let a venue publish an offer.
This role structure addressed a trust problem at the start. Guests need to know that the venues and passes in the app are legitimate.
Getting a guest from discovery to a usable pass
Nightlife software competes with the room around it. The interface has to work in low light, under time pressure, and with one hand.
SipSkip opens with city and venue discovery. Guests browse participating locations, open a venue, and see its current passes. The flow keeps the path to purchase short.
Navigation centers on available venues, owned passes, and account controls. Venue imagery and the public offer help guests recognize a location without reading a long directory profile.
The purchase screen shows the pass, quantity, payment method, and total together. A change updates the amount on screen, and the confirmation control stands apart from ordinary navigation. After payment, the guest receives an active pass with a clear redemption state.
A pass staff can verify at the bar
The value of a pass is decided at the bar, where neither the guest nor the bartender has time to troubleshoot a complicated screen.
The dedicated redemption screen uses high contrast, limited information, and a control that resists accidental taps. Screen brightness and orientation behavior help staff read it in a busy venue.
The application distinguishes available, redeemed, and expired passes. The service remains authoritative for that state, preventing a local animation or old screen from creating a second valid use.
Once staff confirms redemption, the app gives immediate feedback and moves the pass into history. The guest can understand that it has been used, the bartender does not need to perform manual bookkeeping, and the venue gains a consistent record of completed service.
Venue approval as part of the product
An open marketplace where anybody could pose as a bar and accept money would expose users and the brand to obvious fraud. Priority Soft identified this risk during discovery and made approval part of venue onboarding.
A prospective venue submits the required public information and assets through a controlled application. The listing stays outside guest discovery until an administrator reviews it. Approval activates the venue experience; rejection can return a reason without granting management privileges.
The platform decides which venues may publish offers. Each approved manager remains responsible for its location and staff.
The public case study does not include private venue applications, internal review criteria, commercial agreements, or business records. It explains the safeguard without exposing the information used to administer it.
A public offer that a venue can adapt to the night
Demand varies across venues and even across the same evening. A fixed platform-wide pass would not reflect the differences between a quiet bar, a crowded club, and a special event.
SipSkip lets authorized venue managers control the public pass offer available to their guests. They can adjust the current pass and related drink choices within the rules established by the platform. The consumer app always retrieves the active configuration before confirming a purchase.
One set of product rules calculates the selected pass, quantity, service components, credit, and displayed total from checkout through the completed transaction record.
Testing changed the commercial model. Priority Soft separated the priority service from added drink choices in the purchase flow. Venues gained more control over the offer, and guests could understand the total. The client's private revenue arrangements remain confidential.
Payments connected to product state
A card charge must create the correct pass, apply eligible credit once, preserve the transaction state, and recover from an interrupted payment.
Stripe events connect to SipSkip's purchase records. Stripe keeps the card details, while SipSkip stores the information needed to confirm whether the purchase completed.
Returning guests can use saved methods or Apple Pay. The checkout applies credits and public promotions before confirmation and keeps the final amount visible. SipSkip checks duplicate or delayed provider messages against the stored purchase, which prevents a second pass.
The platform also supports a recurring pass through app-store-compatible subscription management. It synchronizes entitlement state with the user's account, so checkout can recognize an active membership from the service record.
Bartenders as a real product role
The person validating a pass should not need the venue owner's login. SipSkip includes a dedicated bartender role with an invitation path tied to the relevant venue.
Staff onboarding uses short steps. A venue manager creates or invites a bartender, the staff member completes the required account setup, and the platform limits access to the actions needed during service.
Visual identifiers help a venue distinguish participating staff. Redemption records connect the pass with the staff member who handled it, supporting accurate operational review without exposing that information to other guests.
The platform can also support direct staff payouts through Stripe Connect where enabled. Payment-provider onboarding and eligibility remain with Stripe, while SipSkip reflects the status needed for the venue workflow. Personal payout information and private performance records remain inside authorized views.
Other venue services
The original priority-pass idea created a foundation that could support other limited-capacity services. Priority Soft extended the product model to door-line passes, grouped offers, and reservable venue sections without forcing each one into an identical interaction.
VIP sections need availability, a time window, booking status, cancellation rules, and a venue relationship. SipSkip presents them as reservations with their own flow.
Pass bundles remain linked to the underlying venue offer and redemption rules. A subscription changes eligibility at checkout but does not bypass pass creation or staff confirmation.
This product structure allowed SipSkip to expand while keeping each purchase understandable. Guests can see what they are buying, and venue staff can see which action the guest is entitled to receive.
Referrals that become accountable product credit
Sharing can help a city-based marketplace grow, but an uncontrolled reward can be abused long before it brings a genuine customer.
Referral links connect an invitation with account registration and a qualifying product event. Credit is recorded within the payment system and can be applied to a later eligible checkout.
The application uses mobile deep links so a shared invitation can open the correct part of the app and retain the referral context. Separate campaign and ambassador concepts give the platform room to distinguish ordinary user sharing from organized promotion.
This public case study omits reward amounts, campaign performance, and anti-abuse rules. A referral earns credit after a qualifying product event, not after a link tap.
Notifications with a place in the venue experience
SipSkip can send mobile and in-app notifications for purchases, referrals, bookings, and venue communication. Each message can open the relevant part of the product.
Notification targeting follows existing city, venue, and role boundaries. Administrators select the audience, while recurring messages use the configured local time for each city.
The in-app notification center gives users a persistent place to review messages after a push banner disappears. Read state is stored with the account, helping the interface distinguish new information from earlier activity.
Notification permissions remain under the user's device controls. The app records the delivery identifiers it needs without turning personal location history or private behavioral data into public product content.
Nightlife-focused design with production restraint
SipSkip uses a dark visual system built around black surfaces, strong red actions, bright pass states, and a gold treatment for membership. The style matches the nightlife setting while preserving enough contrast for fast reading.
Custom pass cards, bottom sheets, persistent actions, and touch interactions fit the mobile context. Short motion cues, including purchase confirmation, add character without delaying access to the pass.
The team also designed the states users encounter when something goes wrong or remains unfinished: unavailable venues, interrupted payments, expired passes, missing location permission, empty history, and incomplete staff setup.
This balance matters. A bold interface can make the product memorable, but the purchase and redemption states must remain unambiguous when money and in-person service are involved.
A mobile and service platform built by domain
The iOS and Android application is built with Flutter and Dart. Feature-specific state management keeps venue discovery, checkout, passes, staff tools, referrals, notifications, subscriptions, and profile behavior isolated while still sharing a consistent application shell.
The service layer uses Django, Django REST Framework, and PostgreSQL. Separate domain modules manage accounts, venues, passes, payments, staff, reservations, referrals, and notifications. Redis supports the workloads that benefit from caching or background coordination.
Firebase provides identity, mobile messaging, and media storage. Stripe handles payments and connected-account capabilities, while RevenueCat synchronizes mobile subscription state. Supporting services provide phone verification, venue location assistance, deep links, transactional messages, and production error visibility.
Each component has a specific product responsibility. This public case study omits private routes, data structures, deployment identifiers, source locations, and provider settings.
Product judgment throughout the engagement
Before launch, we identified the fake-venue risk and recommended approval with separate roles. The first release stayed centered on discovery, purchase, and redemption.
We advised against features that would add compliance and operating work before the central experience had been proven. Alongside development, we prepared mobile-store requirements and delivered test builds. Feedback from those builds led us to reshape the commercial presentation when the first pass model proved too limiting.
The platform later extended the same foundations to staff, subscriptions, referrals, and reservations. We also designed investor-facing visuals that explained the application without exposing its internal systems.
The product work kept SipSkip's nightlife features connected within one working marketplace.
Responsible boundaries around nightlife service
SipSkip helps participating venues sell and verify priority services. It does not replace a venue's responsibility for age checks, alcohol-service rules, capacity, staff training, licensing, or a decision to refuse service.
Date-of-birth collection and controlled venue participation support the authorized venue staff who perform legal and physical checks. The app does not claim that an account profile proves legal eligibility to purchase alcohol.
Payment and payout providers retain their own onboarding and compliance requirements. Venue and bartender approval inside SipSkip does not override those external decisions.
The software coordinates discovery, purchase, entitlement, and redemption. The venue remains responsible for operating the service under applicable law.
The outcome
SipSkip became a two-sided mobile platform for guests, venues, bartenders, and administrators. Guests can find participating locations, buy and present a priority pass, manage past or active passes, and use supported credits or membership benefits.
Venue teams can complete controlled onboarding, manage public offers, invite staff, review redemptions, and handle reservations through authorized views. Shared transaction state connects the guest and venue workflows. The bold design suits a nightlife setting.
Priority Soft handled product definition, design, mobile and backend engineering, payment integration, and later iterations. SipSkip now has the foundation for a nightlife marketplace. This public account omits the client's private economics, venue records, personal data, and sensitive implementation details.
