Asher Atlas

Problem

We were launching the first-ever music livestreaming commerce platform with no users, no infrastructure, and no playbook. Midway through, load testing I initiated revealed the platform would collapse under festival traffic — and leadership didn't want to slow down to fix it.

The Hard Call

I had to choose between staying quiet and hoping the load wouldn't materialize, or persistently escalating until I changed the roadmap. I built a case with data, found internal allies, and kept raising the issue in every forum until I won the reprioritization.

What I Did

• Shipped the 0→1 platform: concept → 100+ live events with integrated ticketing, merch, and artist tooling
• Initiated load testing against stakeholder traffic estimates — found a 2K ceiling with 8K expected at peak
• Built the internal case for reprioritization and drove alignment against executive resistance to delay new features
• Led the infrastructure scaling work alongside engineering, increasing capacity 4x before the festival deadline

Problem

Board game recommendations are genuinely hard. Player constraints are complex and contextual ("something for 5 people, not too long, my group hates trading"). LLMs hallucinate on incomplete metadata. And users don't trust suggestions that feel mechanically correct but miss the actual situation. Generic AI recommendations weren't solving this.

The Hard Call

After shipping V1, I discovered two wrong assumptions at once. The engine was matching on keywords but not reasoning — it couldn't interpret the intent behind a contextual request, only filter on surface constraints. And my entire feedback loop was built on power users, not the casual players I was designing for, so I'd been optimizing for the wrong problems. Rather than patch either one, I rebuilt both: the architecture and the validation methodology.

What I Did

Architecture

• V1: Built a 5-node hybrid pipeline combining deterministic constraint filters with LLM result formatting. Shipped and tested.
• Identified that V1 matched on surface keywords but didn't reason — it couldn't understand the tradeoffs behind a complex, contextual request
• Ran a structured 6-model evaluation before committing to V2 — selected on failure mode severity, not benchmark scores
• V2: Added a dedicated Intent Interpreter node to reason through user requests before passing to the matching pipeline — separating understanding from retrieval
• Built a multi-model metadata enrichment pipeline to clean inconsistent fields across the catalog, reducing hallucinations at the reasoning stage

Validation

• Discovered that all early beta testers were power users — not the casual players I was building for — and their feedback was pushing me to solve the wrong problems
• Rebuilt validation around the actual target audience; redirected ~40% of planned bug fixes that only affected power-user edge cases
• First round of casual-player testing returned immediate positive signal and surfaced real gaps the power-user feedback had masked

Problem

A significant portion of our music catalog disappeared overnight due to licensing changes. Users couldn't find what they searched for, couldn't spend their credits, and were canceling. Support tickets spiked. We needed to stop the bleeding without the catalog back.

The Hard Call

The obvious path was to wait for licensing resolution and run damage control. Instead, I pushed for a structural fix: redesign search to surface discovery when exact matches fail, turning the missing catalog into a recommendation opportunity.

What I Did

• Proposed and led a Netflix-style fallback model: when a search fails, surface similar and trending albums instead of a dead end
• Added two region-specific features: "Most Purchased This Week" chart and a real-time "Last Purchased" ticker
• Managed alignment across design, engineering, and marketing to ship under pressure