Building in Public: What We Shipped in 90 Days

Ninety days ago, JamCrew existed as a brand kit and a conviction that the live events industry deserved better tools. Today it is a working platform: multi-tenant workspaces, crew profiles, gig scheduling, a messaging system, payroll tracking, and a mobile PWA that crew members can install on their phones. This is the honest story of what happened in between.

What We Actually Shipped

The first milestone was the multi-tenant foundation. Every production company that signs up gets their own workspace with custom branding, a unique subdomain, and isolated data. This was not glamorous work, but it was foundational. Getting tenant resolution, theming, and data isolation right in week two meant every feature built afterward worked correctly for every workspace automatically.

Crew profiles came next. Name, skills, certifications, availability preferences, and contact information. Simple on the surface, but the data model had to account for crew members who work with multiple production companies simultaneously. One person, multiple workspaces, different roles in each.

Gig management was the centerpiece. Creating gigs with venue details, call times, roles needed, and rates. Sending offers to crew. Tracking confirmations, declines, and no-responses. The status system alone went through three iterations before it felt right: six default statuses with the option for companies to add custom ones from a curated palette.

Scheduling tied gigs to a calendar view. Messaging gave crew and producers a channel that was not buried in a group text. Payroll tracking connected hours worked to rates agreed, producing clean pay calculations that crew members could verify themselves.

The mobile PWA was a parallel effort running throughout. Every feature had to work on a phone screen first. Touch targets sized for real hands. Offline capability for venue basements with no signal. Install prompts timed for the right moment, not the first visit.

What Surprised Us

The hardest problems were not technical. Tenant isolation, real-time messaging, and PWA service workers are complex engineering, but they have known solutions and clear documentation. The hard part was making decisions about the product itself.

How many default statuses should a gig have? Six felt like too many during design. In testing, it was not enough, which led to the custom status system. Should crew members see their reliability score? The data is useful for scheduling, but exposing it changes behavior in ways that are not always positive. These questions do not have answers in a technical reference. They require judgment, and judgment requires talking to the people who will use the product.

We got the initial onboarding flow wrong twice. The first version asked for too much information upfront. The second asked for too little and left workspaces feeling empty. The current version strikes a balance: enough to be useful immediately, with progressive disclosure for the rest.

The Decision to Build in Public

Building in public is a bet on transparency. Every changelog entry, every blog post, every feature announcement gives potential customers and competitors a clear view of what we are doing and how fast we are moving. The upside is trust. People who follow the journey become invested in the outcome. They offer feedback, report bugs, and root for you in a way that a polished launch page never inspires.

The downside is accountability. When you say you will ship something next week, people remember. When a feature takes longer than expected, the delay is visible. This pressure is uncomfortable and useful in equal measure.

What Comes Next

The next 90 days focus on depth over breadth. The features are in place. Now they need to be refined based on real usage. Client management, the third pillar alongside crew and events, is the next major addition. Equipment tracking, advanced scheduling rules, and deeper analytics are on the roadmap.

We are also preparing for our first production companies to go live. Real data, real gigs, real crew members relying on the platform to get their call times and their pay right. That is the test that matters. Not whether the code compiles or the design looks good in a mockup, but whether a crew lead in a loading dock at 6 AM can pull up their phone and see exactly where they need to be.

Ninety days is a start. The product is real, but it is not finished. Nothing worth building ever is at day 90.