Skip to content
Kisum • Documentation

Frontend Applications

Related documentation: Frontend Implementation · Frontend Admin · Frontend Venues · Frontend Artist

Purpose

Section titled “Purpose”

This page is the runtime inventory of frontend applications that actually exist in the Kisum workspace.

It is not a target-only taxonomy.

For each app, the job here is to say:

  • what repo exists
  • what it currently does
  • what is already implemented
  • what is still pending or intentionally out of scope

Current application landscape

Section titled “Current application landscape”

Kisum is not running as one frontend.

The active workspace currently includes:

RepoPrimary roleStatus
Frontend-Kisummain promoter/base product appimplemented, large legacy-heavy surface
Frontend-Kisum-Adminplatform staff control planeimplemented
Frontend-Kisum-Financefinance workflow UI + vendor portalimplemented
Frontend-Kisum-Venuesvenue-operator CRMimplemented
Frontend-Kisum-Artistsartist / agency operational appimplemented
Frontend-Kisum-Promotersdedicated promoter persona appimplemented
Frontend-Kisum-Websitemarketing site + checkout handoffimplemented
Frontend-Nextktticket sales storefront prototypeimplemented, frontend-only prototype
System-Kisum-Checkoutpayment/signup app at checkout.kisum.ioimplemented, but documented under backend systems because it is a fullstack BFF

1. Frontend-Kisum

Section titled “1. Frontend-Kisum”

Purpose

Main product app for the legacy/base promoter surface.

Current reality

  • large Next.js App Router codebase
  • still carries broad domain assumptions from the older monolithic product
  • still owns major promoter-facing business UI
  • not replaced by Frontend-Kisum-Promoters yet

Documentation note

This app remains important, but the workspace now also has a separate dedicated promoter app. Docs must not pretend the promoter persona is served by only one frontend.

2. Frontend-Kisum-Admin

Section titled “2. Frontend-Kisum-Admin”

Purpose

Platform staff control-plane UI.

Current reality

  • React Router 7 + React 19 SPA
  • browser talks to Backend-Kisum-Admin, not directly to Auth/Core module internals for control-plane work
  • live route families already include dashboard, artists, contacts, admin-users, app-users, venues, settings, and artist-company request review

Detail page

3. Frontend-Kisum-Finance

Section titled “3. Frontend-Kisum-Finance”

Purpose

Finance-domain product UI for internal finance teams plus the vendor portal.

Current reality

  • separate Next.js app
  • internal authenticated route tree for bills, invoices, vendors, users, companies, business units, Xero, errors, docs
  • separate vendor route tree for vendor login and vendor bill submission/history
  • still carries its own app-local auth/session/company context patterns

Implemented now

  • internal finance dashboard and company/business-unit navigation
  • bills, invoices, overdue bills, vendors, users, my-team, error review
  • Xero callback and company Xero pages
  • vendor login, vendor bills list, vendor bill detail, vendor bill create flow

Still not true

  • this repo is not a source of backend finance truth
  • this repo does not own schema, Prisma, Xero secrets, S3/SES credentials, or AI extraction credentials

4. Frontend-Kisum-Venues

Section titled “4. Frontend-Kisum-Venues”

Purpose

Venue-operator operations app at venues.kisum.io.

Current reality

  • standalone Next.js 16 app
  • live Auth bootstrap and venue module gating
  • Phases 1–10 documented as shipped in repo TODO/changelog

Implemented now

  • venue settings + spaces CRUD
  • availability blocks/calendar
  • bookings lifecycle
  • customer overlays
  • deals and contracts
  • deposits and finance visibility
  • venue provisioning gate
  • events
  • operations checklists + templates
  • reports

Detail page

5. Frontend-Kisum-Artists

Section titled “5. Frontend-Kisum-Artists”

Purpose

Artist / agency operational app at artists.kisum.io.

Current reality

  • standalone Next.js 16 app
  • hard no-agency gate is live
  • FE-Phase 0–7 plan is closed in the repo TODO

Implemented now

  • auth/bootstrap + app shell
  • artists / companies / people / roster surfaces
  • representation and claims
  • availability
  • booking requests, offers, bookings
  • contract templates + booking-linked contracts
  • touring + itinerary
  • logistics approvals
  • relationships and trust
  • dashboard, activity, tasks
  • finance visibility
  • agency provisioning under Settings -> Agency

Detail page

6. Frontend-Kisum-Promoters

Section titled “6. Frontend-Kisum-Promoters”

Purpose

Dedicated promoter persona app that consumes Backend-Kisum-Promoters plus the Artists/Venues network BFFs.

Current reality

  • Next.js app with active route groups under @main, public, and api
  • repo README is stale and must not be treated as the runtime contract
  • repo TODO is the accurate implementation tracker

Implemented now

  • booking IA split (/booking/*) replacing the legacy /market/* write flows
  • billing page under /profile/billing
  • booking marketplace, requests, offers, confirmed bookings, relationships
  • dedicated /booking/agencies
  • venue marketplace and venue bookings outbox
  • dashboard booking KPIs
  • public event pages
  • legacy promoter CRM surfaces like dashboard, vendors, workspace, events, AI/research, market analysis

Still pending / partial

  • some Phase B/C follow-ups in the repo TODO, such as deeper venue-booking detail and marketplace artist tab
  • legacy README refresh

7. Frontend-Kisum-Website

Section titled “7. Frontend-Kisum-Website”

Purpose

Public marketing site.

Current reality

  • Vite + React SPA
  • direct browser-safe calls for pricing/geo/checkout handoff flows
  • module landing pages, pricing, and account-creation step 1

Implemented now

  • homepage and module marketing pages
  • pricing page
  • /create account/company form
  • checkout bridge toward System-Kisum-Checkout
  • waitlist modal

Important rule

This app is not the payment processor UI and not the identity backend. It hands off to Checkout for card/payment flow.

8. Frontend-Nextkt

Section titled “8. Frontend-Nextkt”

Purpose

Ticket sales storefront prototype for event discovery and event-detail purchase UI.

Current reality

  • standalone Next.js App Router app
  • public front page at /
  • static event detail pages at /events/[slug]
  • no backend ticketing contract, checkout session contract, auth dependency, or persistence layer yet

Implemented now

  • future events carousel
  • featured events section
  • event box grid
  • compact event cards
  • standing-only ticket detail design for GA-style events
  • mapped venue detail design for GA, VIP, and table inventory

Still not true

  • it is not the ticketing backend
  • it does not own payment execution
  • it does not define event inventory source of truth
  • it does not integrate with Auth/Core/Promoters/Venues yet

Detail page

Documentation rule

Section titled “Documentation rule”

Frontend docs must now separate three states explicitly:

  • implemented now
  • not implemented yet
  • target architecture

If a page only describes the target while a repo already ships real routes, that page is stale.