Once Makes \$22K/mo: Vibe-Coded with Claude Code (Case Study)

Once reached $20K a month within 83 days of launch and about $22K a month at the time of its Starter Story interview. It is a disposable-camera app for events, built by Brian Shin and his girlfriend. Claude Code, Anthropic's AI coding agent, was the main development tool.

It charges once per event, with no subscription. And the founders refused to build until strangers had committed real event dates.

The core point: they proved demand with a hard number before writing production code, then priced the product the way people already think about events.

The problem it solves

Event photos usually end up scattered across guests' phones. Once turns every guest's phone into a shared disposable camera. Guests join an event, shoot a limited number of shots, and the photos reveal together later.

The limits are the product. Fewer shots and a delayed reveal copy the feel of a paper disposable camera. That makes it fun, not just another shared album.

How it was built

Brian previously built a venture-backed B2B startup with about 50 people. After discovering the indie hacker community, he switched to bootstrapping (building without outside investors). The interview does not say how much he coded himself before.

The stack is lean:

• Figma for design. He deliberately kept AI out of design, saying it needs human taste.
• Claude Code as the primary coding tool.
• Conductor, a tool for running several Claude Code agents in parallel.
• Supabase, a hosted database with file storage and login.
• Vercel for hosting the web app.

The first version was a simple web app, built in one to two weeks for a Halloween party. It was a test, not a launch.

How it makes money

Once charges per event, not per month. The pricing page says you pay once per event, with no subscriptions or renewals.

• Personal: free for up to 5 participants.
• Unlimited shots add-on: $9.99, one-time.
• Events: the price scales with guest count, from 5 up to unlimited participants.

Starter Story gives the range. A 10-person birthday costs about $2. A 150-person wedding costs about $50. The pricing page itself did not show exact tier prices when we checked.

Per-event pricing fits the buyer. Nobody wants a subscription for a wedding they have once. A one-time price is easy to say yes to, and it grows naturally with the size of the event.

Volume did the rest. Starter Story reports about 300 events scheduled in February 2026 and about 700 in March. It also reports 10,000–12,000 weekly active users. Every guest at an event also sees the app, and some of them will host events of their own.

How the first users came

Before building, the founders set a "commitment metric": 10 confirmed events with real dates. As Starter Story puts it, they picked a number and did not start building until they hit it.

Here is how they got there:

1. Personal network. They went through contacts on X, LinkedIn and Instagram. Four friends had upcoming events.
2. Instagram cold DMs. They searched hashtags like #wedding and #birthdayparty and messaged 250–300 people.
3. Results. About 15 replied, and they booked 12 events that month.

That beat the target. Only then did they build out the full product. Brian also jokes about how hard they pushed outreach, saying you have not tried enough until a platform has banned you a couple of times.

What to copy

• Set a commitment number before you build. Real dates beat "sounds cool" feedback.
• Cold DM by hashtag. Hashtags tell you who has an event coming up.
• Price the way buyers think. Events are one-off, so the price is one-off.
• Design the constraint. Limited shots and a delayed reveal are the hook.
• Let every user be an ad. Each guest sees the app at the event.

If you vibe-code this

Private photo sharing with guests who may not have accounts is tricky. Check these:

1. Use unguessable event links. Event IDs like 1, 2, 3 let anyone walk through other events. Use long random tokens. See IDOR in API routes.
2. Keep photos in a private bucket. Serve them with signed URLs, links that expire after a few minutes. See storage bucket security.
3. Enforce the reveal time on the server. If the reveal is hidden only in the app screen, photos can still be fetched early.
4. Enforce shot limits on the server. Otherwise a script can upload without limit. See API rate limiting and file upload security.
5. Lock down tables with Row Level Security (RLS). RLS is Supabase's per-row access rule. See Supabase RLS for vibe coders.

A server-side check before handing out a photo link, using supabase-js:

const { data: event } = await supabase
  .from("events")
  .select("reveal_at")
  .eq("id", eventId)
  .single();

if (!event || new Date(event.reveal_at) > new Date()) {
  return new Response("Not revealed yet", { status: 403 });
}

const { data, error } = await supabase.storage
  .from("event-photos")
  .createSignedUrl(`${eventId}/${photoId}.jpg`, 600); // 10 minutes

Building a private sharing app and want the links, storage and reveal logic checked? Email me at [email protected] for a security audit.

Key takeaway

Once shows that Claude Code can get a product built fast, but the founders spent their energy on proof first. Ten real event dates, then code. Per-event pricing, then volume.

More case studies: vibe-coded apps making money. Before you launch: the vibe coding security guide.

Sources

• https://www.starterstory.com/brian
• https://www.bulletpointpodcast.com/starterstory/i-built-a-20-k-month-app-in-83-days
• https://once.film/pricing