I designed and built a recruiting platform where each decision a recruiter makes triggers the right downstream actions automatically. The current rollout begins with one client running two weekly events, with expansion planned to roughly 10 weekly events nationwide by the end of Q3. Historically, the business has needed to support 3 to 5 clients at a time.

Roadshow Staffing runs product demo events in warehouse clubs across the country. New events open every week in new cities, always on fixed dates, always staffed by gig workers whose availability can change quickly. Someone has car trouble. Someone gets sick. Someone disappears for a while, then comes back months later asking if anything is available nearby.

The recruiting team did not treat that as noise. They tracked it all, because this was relationship work. A candidate who is unavailable today might be exactly who you need for next week’s event.

When I first came on in 2017, applications were coming in by email and the pipeline lived in Google Sheets. I moved the team onto Airtable. Forms replaced raw email intake, the data flowed into a shared database, and for the first time the team could see the pipeline together.

This project grew out of earlier operational conversations in November and December 2025 about how the business actually worked. Focused product discovery on rssHQ began in January 2026, once it was clear the real problem was not just tooling friction, but a workflow the existing system could not hold.

That was a real improvement. But the work moved too fast for a system that required recruiters to open individual records and reconstruct what a status actually meant. When an event had to be staffed by Thursday, buried candidates were not just inefficient. They created real operational risk.

The obvious fix was more Airtable automation. Connect the tools. Add triggers. Clean up the statuses.

That would have made things worse.

The problem was not that the status labels were messy. It was that the labels had no relationship to the work they represented. “Interviewing” did not send the invite, coordinate the time, surface the NDA, or link notes back to the applicant record. It just recorded a choice. Everything that needed to happen next still lived in the recruiter’s head and in whatever patchwork of tabs, templates, and habits they had built to keep the process moving.

The real design problem was:

How do we build a system where making a recruiting decision and doing the work that follows are the same gesture?

That question changed the project. It moved the work from workflow cleanup to workflow design.

I knew the team had outgrown Airtable. I did not understand how deeply until I sat with the actual workflow.

The first signal was small but telling: recruiters were adding context directly into applicants’ names. Not into notes, not into a dedicated field, but into the name itself. That is what happens when every legitimate place for information is already full.

The status model showed the same problem at a larger scale. One label could stand in for several different situations. “Interviewing” might mean an invite had been sent, an interview was scheduled, an interview had already happened, or notes were still missing. The only way to know which one applied was to open the record and read through history.

That history lived in a free-text outreach log everyone used differently. Some entries were shorthand. Some were full sentences. Some only made sense if you already knew who wrote them. The column was doing real work, but it was doing it in a way the system could not reliably support.

The more I worked through the process with the founder and recruiter, the clearer the actual shape of the work became: applicants do not move through a clean, linear pipeline. Good candidates go quiet and resurface later. Strong people who are unavailable for one event need to stay visible for the next one. The team did not just need to know a person’s status in one moment. They needed continuity over time.

The system could not hold that complexity, so the team compensated for it manually. They remembered who was warm, what shorthand meant, what still needed follow-up, and who might be right for a future opening. They were working hard to make up for a tool that could not model the work they were actually doing.

That insight led to the central product decision: status should be the output of a decision, not the input.

In the old workflow, changing a status was the first step. Everything after that was manual. In rssHQ, the recruiter makes a judgment call about a person, and the system handles what follows.

That meant redesigning the interface around actions instead of labels. Instead of choosing from a dropdown of statuses, recruiters see one clear primary action and a small set of escape hatches. The interface answers a practical question: what should I do next with this person?

The prototype that proved it

I did not arrive at that model by intuition alone. I built the wrong version first.

The first working prototype used a status dropdown. The idea was to let recruiters change the status and have the system trigger the next steps from there. In practice, it added cognitive load instead of removing it. The menu showed too many possibilities, changed depending on context, and created hesitation. Recruiters paused because they were not sure what would happen next or what they were committing to.

That hesitation was the signal.

The problem was not the word itself. It was the abstraction. “Interviewing” named a state. The recruiter did not need to declare a state. They needed to take an action: invite this person to interview.

One is a label. The other is a commitment that triggers a sequence.

That was the turning point.

The final interaction model reduced the interface to one contextual primary action and a small overflow of exceptions. The primary label told the recruiter what to do next, not what state to set. Missing interview notes redirected the action to Add Recruiter Notes instead of blocking someone later in the flow. Pass never appeared as the primary action, and terminal states like Hired or Pass rendered no controls at all. The result was a system that made the right path obvious, kept destructive paths effortful, and handled finality cleanly.

The nuanced calls

Not every design decision was about simplification. Some were about preserving nuance without letting ambiguity take over.

I kept Hold, even though I was tempted to remove it. The team was attached to it, and it captured something real in their process. But I changed the rules around it: a Hold required a reason. A blank Hold is a parking lot. A Hold with a note is a decision.

I also chose not to allow completely free movement through the workflow, but I did not make the system rigid. Recruiters could skip steps when needed. The difference was that skips were logged, with reasons, in the activity history. Nothing disappeared silently. That served both the team’s day-to-day clarity and the traceability the business needed for audits and compliance.

The founder initially worried that the system was becoming too opinionated. I held the line because the tradeoff was worth it. The friction of a structured decision costs seconds. The manual work it replaces costs hours.

How I worked

This project was not just interface design. I was also defining the product logic the system would enforce.

I ran recorded working sessions with the founder and recruiter, translated those into workflow definitions and product documents, and tracked key decisions as the system evolved. I started that structure in Notion, then used Linear to operationalize it into implementation-ready work. Tickets were written as true user stories, not just engineering tasks, so Claude Code had concrete user context, edge cases, and success conditions to build against. I defined the workflow model, interaction design, and decision rules, then used AI-assisted coding tools to implement and iterate quickly. AI accelerated execution; it did not decide the product.

The clearest example is the interview invite flow.

Before rssHQ, moving someone to interview meant finding a time, drafting a message, copying over the email, sending it, coordinating back and forth, adding the appointment to a calendar, and then returning to Airtable to update the record manually.

The tool is still in rollout, so I’m not putting a stable time-saved number on this yet. What I can say clearly: this workflow moved from seven manual steps across messaging, scheduling, calendar coordination, and record updates into one in-system action, with the downstream steps triggered automatically.

The invite goes out with scheduling built in. The applicant picks a time. The calendar updates. The record updates. The recruiter follows up only when follow-up is actually needed.

Other outcomes mattered too:

• Reference checks became feasible inside the same workflow. What would have been a fragile multi-table process in Airtable became a straightforward extension of the platform.
• Records became more trustworthy. The team no longer had to decode shorthand or wonder who handled what.
• The system fit the business model better. Instead of forcing a gig-work operation into tools designed around cleaner, more static hiring flows, rssHQ matched the way recruiting actually moved.

The headline result was not that recruiting became simple. It was that the system finally carried more of the complexity itself.

I did not arrive at the right model all at once. Airtable was part of the learning curve: it improved visibility, but it also exposed where the workflow still depended on memory, shorthand, and judgment.

With rssHQ, I kept the build layered for the same reason. Each working version helped reveal the next layer of complexity, which let me test whether the model was getting clearer or just more complicated.

Lovable was especially useful at that stage. Getting an interactive prototype in front of the team quickly made it much easier to tell whether we were heading toward the right system or encoding the wrong one.

Roadshow Staffing did not need a shinier recruiting tool. They needed a system that finally matched the complexity of the work they were already doing.

The workflow itself did not change: new events, new cities, real people with unpredictable lives, clients who never see the logistics. What changed was where the work lived. Not in someone’s memory, not in a shorthand column only one recruiter could decode, but in a system opinionated enough to handle what came next, so the recruiter could focus on making the next call.