Case Study HYSS

Book, schedule and pay your AV crew from one system.

HYSS gives AV and live-events companies one place to staff a show, catch a conflict before it lands, and pay everyone after. Freelancers keep a profile, share availability, and get paid. We built the platform architecture and backend, with a conflict engine that validates every booking and billing that stays private across shared jobs.

Client: HYSS
Sector: AV & live events · Crew ops
Engagement: Platform architecture & backend
Stage: Live
Platform: Web · iOS · Android

The HYSS dark homepage hero with the headline There's a better way to staff your events, above the crew booking product — One platform for the whole job: staff the show, catch conflicts, send the call sheet, invoice each client.

By the numbers

3Worker types in one model

Real-timeConflict detection

2-sidedEmployers + freelancers

iOS + AndroidNative apps

AV crew scheduling runs on spreadsheets, group texts and guesswork.

An AV company staffs a show by texting thirty-five freelancers for availability, then cross-referencing the replies against a spreadsheet by hand. The errors hide in that gap.

Two managers book the same engineer for the same Saturday, and nobody finds out until load-in. A client moves an event by a day, and a booking that looked solid quietly breaks. W-9 and COI documents sit in inboxes while someone chases who has sent what. Invoicing crawls across clients who each pay a different rate.

The call sheet is the part everyone feels. You build it, send it, then a detail changes and every copy in every inbox goes stale at once. The version on a phone at the venue is the version that matters, and it is the one most likely to be wrong.

Worker type belongs to the booking, not the person.

Zain built the platform architecture and backend on one idea that shapes the rest. The same person can work as an employee on Monday, a freelancer on Wednesday, and an agency hire on Friday. A worker-source tag on each assignment carries that context, so rates, overtime and cost bucketing resolve from the booking instead of from a fixed profile.

What that meant in practice

A worker-source tag on every assignment that resolves rates, overtime and cost bucketing on its own, and payment routing that keeps each employer's invoices isolated on shared jobs
Shadow profiles that let schedulers plan with unregistered crew, while hard rules block official assignment until that person creates an account
A conflict engine that validates availability before any booking is written and shows an impact diff before a mutation commits, expanding recurring schedules into discrete occurrence rows so recurrence is checked like any one-off
Load-weighted auto-assignment that spreads shifts evenly across the roster, guarded by a boundary-probing test suite over the pay and access rules

Freelancer profiles

Each freelancer carries one profile across every employer.

A freelancer keeps positions, gear competencies and ratings in one place. A scheduler filters the roster by who is free, qualified and nearby, then sends a structured offer the crew member confirms in a tap. The same profile follows that person whether they show up as a freelancer, an employee or an agency hire.

One profile · positions, gear, ratings

Architecture

The conflict engine runs before the write lands.

Before any booking is persisted, the system queries that worker's existing assignments and rejects any time overlap as a validation error. An edit triggers a pre-commit traversal of every affected booking and constraint, then surfaces the violations as a diff the manager reviews before the transaction commits. Recurring schedules expand into discrete occurrence rows, so the engine checks them the same way it checks a one-off.

Pre-commit validation · impact diff before mutation

See it work

Walkthrough: booking crew, catching a conflict, and a live call sheet

Inside the product

A shareable HYSS availability calendar with Google Calendar sync, showing a freelancer's open and booked dates

HYSS invoicing and payment tracking with per-client rate cards and paid, due and overdue status

The hardest part

On a shared job, two employers book from the same roster and each one needs to see its own invoices and never the other's rates. We routed billing through a payment-authority field so the money flows in three directions while every employer's records stay isolated, then pointed a boundary-probing test suite at the exact edges where that isolation could leak.

Ego Eimi Engineering note · the build

Live on web, iOS and Android, with the hard rules locked down.

HYSS is live and two-sided. Employers book, schedule and pay from web and native apps, and freelancers keep a profile, share availability and get paid for free.

One model handles employees, freelancers and agency workers, so a new feature works for all three out of the box. Conflicts get caught at write time before they reach the database, payouts route to the right authority, and the boundary-probing tests keep the pay and access rules honest as the roster grows. Employers pay $75 a month per admin plus 0.5% of labor, with a 30-day trial; freelancers and finance viewers pay nothing.