The decision

A physical venue opening cold needs the door to work on day one. The decision that mattered was to treat the grand opening like a product launch, not a party. Reservations, check-in, and member conversion had to be one instrumented flow, not a clipboard.

What I built

The full stack the venue runs on: marketing site, RSVP with digital check-in, membership signup, a waitlist and live queue board, Resend email flows, and the reporting that shows what the door and the funnel actually did.

Role

Co-founder. Owns digital, the on-site experience, and outreach.

Stack

• Next.js
• Supabase
• Resend
• Vercel

Outcomes

Reservations

190Surge grand opening, Aug 2026.

Registered headcount

367Surge grand opening, Aug 2026.

Verified check-ins

147Surge grand opening, Aug 2026, digital check-in.

RSVP to member conversions

40 (21%)Surge grand opening, Aug 2026.

Signups in the 48h window

104 vs 31 the prior weekSurge launch, Aug 2026, membership signups.

Member community

~255Surge, post-launch member count, Aug 2026.

Launch post views

32.2KSurge launch post, Aug 2026.

Accounts reached in 30 days

25.4KSurge social reach, 30 days from launch, Aug 2026.

The tradeoff

Digital check-in over a faster paper list. It slowed the very first minutes at the door in exchange for a clean count. That count is why 147 check-ins and a 21% RSVP-to-member rate are real numbers and not a guess.

What I would do differently

Open the membership signup earlier in the 48-hour window. The 104-vs-31 spike showed the demand was there before the launch post, and some of it went uncaptured.

The decision

A rated tournament lives or dies on trustworthy brackets and standings. The decision that mattered was to build on DUPR ratings from the start so seeding and results held up to players who care about their number.

What I built

The platform that runs the club: a player roster, tournament brackets and scheduling, and the analytics that turn match results into standings.

Role

Built and operates it end to end.

Stack

• Next.js
• Supabase

Outcomes

DUPR-rated tournament

124 playersDMPC tournament, DUPR-rated field.

The tradeoff

Anchoring to DUPR ratings meant less freedom to hand-seed, and a dependency on an external rating source. The payoff was standings players trusted without argument.

What I would do differently

Model the schedule and court assignment earlier. A 124-player field stresses court time, and that is where a rated event feels either smooth or chaotic.

The decision

A small studio cannot afford an SDR and cannot afford to spam. The decision that mattered was to automate the entire top of funnel except the send. Everything runs on its own, and a human approves before any email leaves. Drafts never auto-send. That approval gate is the whole point: it is what keeps an always-on engine from ever embarrassing the brand.

What I built

Two things. The commerce side: storefront, Stripe checkout, and an in-person POS. And the outbound engine: five agents (finder, analyst, writer, sender, follow-up) plus a daily brief. The finder pulls real companies. The analyst scores fit with Claude vision. The writer drafts in the studio's voice. The sender only sends what a human has approved. The follow-up sequences the ones who go quiet. The daily brief is the operator's one screen each morning: who was found, what was drafted and is waiting on approval, what got sent, who replied, and what needs a human decision. Nothing moves to a send without a click.

Role

Built and operates both the store and the engine.

Stack

• Next.js
• Stripe
• Supabase
• Apify
• Claude vision
• Playwright
• Always-on worker

Outcomes

Engine outcomes

Figures pendingConfirmed figures pending publication.

The tradeoff

The human approval gate caps throughput. The engine could send more if it sent on its own. It does not, on purpose. A slower pipeline that never sends a bad email beats a fast one that burns the domain and the brand.

What I would do differently

Put the daily brief in front of the operator sooner in the build. The approval step is only as good as how fast the human can read and act on it, and the brief is what makes that fast.

The decision

Product imagery is a bottleneck for a studio shipping many SKUs. The decision that mattered was to make the intake and the revision loop feel like texting, so a non-technical operator could drive it from their phone instead of a design tool.

What I built

A pipeline that scrapes a product page, lays out a branded collage programmatically, and generates an AI model shot with a fallback model when the primary fails. Intake and the revision loop run over iMessage. Output lands in Supabase storage.

Role

Built and operates it. Private tool.

Stack

• Vercel functions
• Custom scraper
• Image model with fallback
• Supabase storage
• iMessage intake

Outcomes

Status

Private, in productionPrivate internal tool. No public metrics are published for it.

The tradeoff

iMessage intake over a real UI. It is faster to use and impossible to onboard a stranger to. Fine for a private one-operator tool, wrong for anything shared.

What I would do differently

Design the fallback image model in from day one instead of bolting it on. Image generation fails often enough that the fallback is not an edge case, it is the happy path some days.

The decision

The executive GM was spending 8 to 10 hours a week reconciling five stores by hand. The decision that mattered was to compute true food cost with an inventory adjustment, not just invoice totals, so the weekly number was one a GM could act on instead of second-guess.

What I built

A dashboard that pulls Clover POS, PFG food invoices, and ADP payroll into weekly KPIs: net sales, true food cost with inventory adjustment, and labor including cash payroll. Exception alerts flag the stores that need a look. Claude runs the analysis. A Resend weekly digest lands the summary in the inbox.

Role

Client build. Delivered the system end to end.

Stack

• Clover POS
• PFG invoices
• ADP payroll
• Claude analysis
• Resend
• Supabase

Outcomes

Manual reconciliation replaced

~8 to 10 hours a weekTime previously spent by the executive GM on manual reconciliation across five stores.

Live status

Figures pendingConfirmed figures pending publication.

The tradeoff

True food cost with an inventory adjustment is more work than reading invoice totals, and it needs a count the stores have to actually do. The harder number is the only one worth putting in front of a GM.

What I would do differently

Instrument data quality at the source earlier. The dashboard is only as honest as the Clover, PFG, and ADP feeds behind it, and catching a bad feed fast matters more than any chart.