All Case Studies
Technical Build Story· 4 weeks· $6,200 CAD

How We Built WiKD LiVE

Two-sided marketplace with Stripe ticketing and QR door-scanning. 4 weeks.

Base44ReactStripe ConnectQR Code GenerationGmail OAuthResendDeno Backend Functions
View Full Case Study (Outcomes & ROI) →

The Problem

Canada's independent live music industry had no dedicated marketplace. Venues and artists connected over Instagram DMs. Ticketing went through Eventbrite at 15–20% commission. On a $10,000 event, that's $1,500–$2,000 in fees. The founder needed a two-sided marketplace and direct ticketing platform — fast and at a realistic budget.

Architecture Overview

WiKD LiVE has the most complex architecture of any project we've built on Base44 — two completely distinct user types (artist and venue) with separate dashboards, different entity permissions, and different feature sets. We used Base44's role-based access control to enforce separation: artist accounts can't access venue booking management, and venue accounts can't access artist application management.

The ticketing system is architecturally separate from the marketplace. An event is created by a venue, tickets are sold through Stripe Checkout, QR codes are generated per ticket and stored on the Ticket entity, and the door-scanning flow is a public route that validates a QR code against the Ticket entity without requiring a login. This separation kept the public-facing ticket validation fast and simple.

Database Design

ArtistProfileuser_id, bio, genres[], draw_size, availability[], set_list, media_links[], location, verified
VenueProfileuser_id, name, capacity, location, description, photos[], booking_email, verified
BookingNeedvenue_id, event_date, genre_preferences[], draw_requirement, pay_rate, status, applications[]
Applicationbooking_need_id, artist_id, message, status, submitted_date, response_date
Eventvenue_id, artist_id, title, date, description, ticket_price, capacity, tickets_sold, status
Ticketevent_id, buyer_name, buyer_email, stripe_payment_id, qr_code, scanned, scanned_at
Messagesender_id, recipient_id, content, read, sent_at, conversation_id
Subscriptionuser_id, plan, stripe_subscription_id, status, current_period_end
Reviewreviewer_id, reviewed_id, reviewer_type, rating, comment, event_id

The Ticket entity was the most design-sensitive. Each ticket gets a unique QR code value generated at checkout success — a UUID stored as a string. The QR code image is generated client-side from this UUID using a QR library and embedded in the confirmation email. Door scanning passes the UUID from the QR scan to a backend function that validates it against the Ticket entity and marks it scanned. We deliberately didn't encrypt the QR payload — the UUID is only meaningful against our database, making forgery pointless.

AI Integration

WiKD LiVE has lighter AI usage than Rent Detective or Auto Detective — the core product value is the marketplace infrastructure, not AI analysis. We added an AI booking assistant that helps venues write their booking needs posts (prompts for genre, draw requirement, pay rate) and helps artists write their profile bios from bullet points they provide. Both use GPT-4o via InvokeLLM with simple prompts. The assistant is optional — experienced users skip it.

Stripe Implementation

WiKD LiVE has two Stripe flows: ticket sales and subscription billing. Ticket sales use Stripe Checkout — the backend function creates a Checkout session with ticket quantity, event name, and buyer metadata. On webhook success, a Ticket record is created with a UUID, the QR code generation email is triggered via Resend, and the Event's tickets_sold count increments.

Subscription billing uses Stripe's Subscription API. Artists and venues choose their plan on signup and are redirected to a Stripe Checkout with a subscription price ID. On subscription.created webhook, the Subscription entity is created and the user's role is updated to include their plan tier. Subscription downgrades and cancellations go through a customer portal link generated by a backend function. The biggest implementation challenge was handling the webhook event ordering — subscription.created and checkout.session.completed can arrive in either order. We implemented idempotency checks on both.

Technical Challenges

Dual user type architecture

Artist and venue dashboards share one Base44 app but need completely different navigation, data access, and feature sets. We solved this with a conditional layout component that reads the user's role on login and renders the appropriate dashboard. A user who is both an artist and a venue owner can toggle between modes.

QR ticket forgery prevention

QR tickets that can be screenshotted and shared need a scan-once enforcement. We added a scanned boolean and scanned_at timestamp to each Ticket. The door-scanning endpoint checks scanned === true and returns a 'already scanned' warning with the original scan timestamp, allowing door staff to spot duplicates.

Stripe webhook event ordering

Checkout session completion and subscription creation events from Stripe can arrive in any order. We added idempotency checks — if the Subscription entity already exists when subscription.created arrives, we update rather than create. This made webhook handling robust to race conditions.

Lessons Learned

Two-sided marketplaces need dual user type architecture designed from day one — retrofitting it is a significant refactor.
Stripe webhook idempotency isn't optional. Test with Stripe's webhook replay tool before launch.
QR scan-once enforcement needs to be in the backend, not the frontend. The frontend can lie.
Subscription tier feature gating should be centralized in one utility function — otherwise it gets duplicated inconsistently across 15 different components.

Want the outcomes, ROI, and client testimonial?

The full case study covers results, metrics, and what the client said.

Full Case Study

Related

Want to Build Something Similar?

Free 30-minute call with Ryan. Fixed quote before we hang up.

$100/hr CAD all-inclusive. 2–6 week delivery on Base44.

Book Free Discovery Call

ESTIMATE DISCLAIMER

Any estimates, pricing proposals, or preliminary assessments provided through this website, AI chat, or email are non-binding estimates only and do not constitute formal quotes. Estimates are subject to change and are provided on an "as-is" basis without guarantee. Official quotes are provided only in writing by Level 44 Labs and are subject to revision based on final scope clarification.

QUOTE & PROJECT TERMS

All formal quotes are subject to errors and omissions. Final project scope, timeline, and costs may change based on requirements discovery, technical constraints, third-party dependencies, and client-requested modifications. A formal written agreement must be executed before work begins. Discovery calls are informational only and do not constitute project commitment.

LIABILITY LIMITATION

Level 44 Labs and its representatives shall not be liable for any indirect, incidental, special, or consequential damages arising from estimates, quotes, website content, AI-generated responses, or service delivery. Our total liability is limited to the amount paid for services rendered. Client assumes all risks associated with third-party services, integrations, and platform dependencies.

NO WARRANTIES

All estimates, preliminary advice, and website information are provided "as-is" without warranty. Level 44 Labs does not warrant accuracy, completeness, or suitability for any particular purpose. Clients are responsible for verifying all technical requirements independently.

INTELLECTUAL PROPERTY

Custom work delivered under formal agreement remains the property of Level 44 Labs until payment in full is received. Third-party libraries, frameworks, and Base44 platform code are governed by their respective licenses.

© 2026 LEVEL 44 LABS · ALL RIGHTS RESERVEDBUILT ON BASE44