Designing a Status System That Scales

Every gig moves through a lifecycle. A new offer appears, someone responds, the crew locks in, the show happens, the books close. Tracking where things stand sounds simple until you have 40 gigs running across three cities with 200 crew members rotating between them. Status becomes the single most important piece of information in the entire system.

We spent a long time thinking about how to build a status system that works for small shops running weekend gigs and for large production companies managing national tours. The answer was a hybrid: fixed defaults that cover 90% of workflows, plus a curated extension system for the remaining 10%.

The Six Defaults

JamCrew ships with six statuses baked into the platform. New (sky blue) marks a fresh gig offer that nobody has seen yet. Pending (honey) means a crew member has viewed the offer but has not responded. Confirmed (sage) locks it in, both sides agreed. In Progress (mint) means the crew is on-site and checked in. Cancelled (coral) removes a gig or assignment from active play. Completed (slate) archives the gig once the work is done.

These six statuses map to a clear linear progression. A gig starts as New and ends as either Completed or Cancelled. Every transition between them is intentional. You cannot skip from New to Completed without passing through Confirmed. You cannot move backward from Completed to Pending. These constraints prevent data integrity issues and ensure that timesheets, invoices, and reporting all reflect what actually happened.

We chose these six because they describe the universal workflow of live event staffing. Every production company we spoke to during research used some variation of this same lifecycle. The labels might differ, but the underlying states were consistent.

When Defaults Are Not Enough

Some teams need more granularity. A large AV company might want an "Equipment Loaded" status between Confirmed and In Progress. A staffing agency might need "Awaiting Client Approval" as a gate before Confirmed. A touring production might add "Travel Day" as a distinct state.

Rather than trying to anticipate every possible workflow, we built a custom status system. Admins can create up to ten additional statuses, name them whatever they want, and assign them a color from a curated palette. Custom statuses slot into the lifecycle at defined insertion points. They do not replace the defaults. They augment them.

The Curated Color Palette

Early in development, we considered letting admins pick any hex color for custom statuses. We dropped that idea within a day. Arbitrary colors create visual noise. Someone picks a neon green that clashes with the interface. Another team uses three shades of blue that are indistinguishable at a glance. The whole point of color-coded statuses is rapid visual scanning, and that breaks down when colors are not carefully chosen.

Instead, we curated a ten-color palette: Sage, Honey, Coral, Sky, Slate, Violet, Rose, Mint, Tangerine, and Midnight. Each color is distinct enough to be identified at small sizes, works in both light and dark mode, and meets accessibility contrast requirements against the badge background.

Badge rendering uses color-mix(in srgb, var(--status-color) 15%, transparent) for the background tint, with the full color applied to the text. This technique means every status, default or custom, gets the same consistent visual treatment. No special CSS per status. No conditional styling. The color token drives everything.

The Data Model

In Convex, statuses are stored as a combination of a workspace-level configuration table and per-record status fields. Default statuses are seeded when a workspace is created and cannot be deleted. Custom statuses belong to the workspace and include a name, a color key (from the palette), a sort order, and optional transition rules.

Each gig, assignment, or crew record references a status by ID, not by name. This means an admin can rename "Awaiting Approval" to "Client Review" without breaking any existing records. The ID stays the same. The display name is just a label.

Transition rules are optional but powerful. An admin can specify that "Equipment Loaded" can only follow Confirmed, preventing someone from accidentally applying it to a gig that has not been locked in yet. If no transition rules are set, the custom status can be applied freely.

Admin UI

The workspace settings panel includes a status management section. Admins see their six defaults listed at the top, each with its fixed color. Below that, a section for custom statuses with an "Add Status" button. Each custom status row shows the name, the color swatch, and a drag handle for reordering. Clicking a status opens an inline editor for the name, color selection (a row of ten swatches), and transition rules (a multi-select of which statuses can precede it).

The design is intentionally constrained. No color pickers, no gradient options, no icon assignments. Every guardrail exists to keep the system scannable at speed, which is exactly what you need when you are managing a show floor with 50 crew and things are moving fast.