Yonas Media · Internal Tool · Late 2024 – 2026
Yonas Media Tool
Company
Yonas Media
Role
Designer + Developer + Strategist
Type
Internal Tool
Year
Late 2024 – 2026
The Brief
I wasn’t handed this project. I went looking for it. The goal was to find a real company experiencing a real problem — not a hypothetical, not a redesign exercise — and solve it end-to-end. That meant defining what to build, designing it, and building it. Yonas Media was that company. Yonas Media manages roughly 15 active touring artists. Their booking operation ran across a patchwork of disconnected tools: 15 individual Google Sheets (one per artist), a Streak CRM holding 9,000+ venue records that wasn’t connected to the booking calendar, a separate Polestar venue directory, and verbal and email handoffs between three core team members. The first thing I needed to understand wasn’t what to build — it was the shape of the business. Where was it today? Where was Ben trying to take it? What did scale look like for a company like this? That informed everything downstream: the backend architecture, the data model, the role system. Building something that solves today’s problem while boxing you into a corner for tomorrow isn’t solving the problem. From those early conversations, a clear brief emerged: replace the stack with one tool. A single live view of artist availability, booking status, and venue data — built for the team’s actual workflow, not a generic CRM.
The Hidden Cost
Before writing a line of code, we timed the work. Benchmarking with Ben revealed that evaluating a single booking inquiry — checking artist availability, cross-referencing routing, looking up a venue — took 13 minutes. He handles 10 to 15 of them a day. Downstream, Kylie was spending 1 minute 15 seconds re-entering confirmed booking data into the contract system — the same data Ben had already entered, copied by hand. Two people. Two workflows. Both measured before the tool existed so the after numbers would mean something.
Built Around How They Think
The decisions that shaped the tool didn’t come from a brief — they came from the team. Ben’s exact words in a working session were what changed “Cancelled” to “Need to Fill”: a fallen-through show isn’t dead, it’s an open routing date that needs filling. Kylie’s frustration with inconsistent city and state data is why those fields are now locked and sourced from the venue database. The 365-row calendar exists because Ben thinks in terms of open dates, not upcoming events. Four decisions, four origins — all drawn from how the team already thought about their work.
Built to Be Used
There was no handoff on this project because there was no one to hand off to. As the designer and the developer, every decision from research to deployment was the same person’s call — which compressed the feedback loop from days to minutes, and meant the tool could be in beta with real users while it was still being built. The constraint was the same one Ben faces every day: booking season doesn’t wait. The tool had to be reliable before it had to be perfect.
A New Baseline
[PLACEHOLDER — Post-launch measurement section. Write once follow-up contextual sessions with Ben and Kylie are complete and after-numbers exist.]
The Result
Reduced booking inquiry time from 13 min to 1 min 10 sec
Reduced contract entry time from 1 min 15 sec to ~5 sec
90% daily active usage across a 15-person team
This is a live product, in active daily use by a team of ~20. The work isn’t finished — it’s in its second cycle, with a third already visible on the horizon. Want to see where this goes next?