miraclecoder
storyworthy

Where the gold is

On April 28th I went to a meetup at Fabrik Tribeca called Beyond Vibe Coding — APIs, run by Jeff Buzulencia’s Product Builders Club. The format was simple. Pick an API. Build something with it before the night was over. Show the room what you made.

I spent about ten minutes building a small Next.js app that asked you to describe the vibe you wanted your apartment to feel like, fed that description to Google’s Gemini API to turn it into structured search queries, and then hit the Metropolitan Museum’s open API to surface real artworks you could hang on your wall. I called it Muse. It still lives in a folder called tinker/ on this same machine.

Then I spent the rest of the evening walking around the room, helping other people get their 3rd-party API calls working.

That is how I met Maurice. I showed him what I’d built. He showed me what he’d built, a site that narrated a sports match in another character’s voice, Rick and Morty, specifically, and his was funny. We exchanged contacts. We didn’t talk much that night. That was it.

A week later, on May 4th, Maurice sent me an iMessage. He reintroduced himself, joked about the Morty voice thing, and asked if I’d want to chat about a few things he was working on. He attached a couple of repos. One was a restaurant reservation booking app. I passed on that one. The repo was already a vibe-coded mess, and even if it weren’t, I couldn’t see a monetization path that worked at the margins restaurants actually run on. The other was a folder called airbnb-hotel-idea-, trailing dash and all. I said yes to that one.

Three reasons, in the order I weighed them. The third is the one that actually mattered.

First, it was early enough. Maurice had pushed one foundational commit (Phase 1: trip planner foundation). The repo wasn’t yet so tangled that turning it into a professionally maintained codebase would be a salvage operation. There is a window in any project’s life where you can still shape it in your own voice without being rude about it, and airbnb-hotel-idea- was in that window.

Second, the monetization path was obvious. Affiliate links to Booking.com, VRBO, Airbnb, Stay22. Each booking pays a small affiliate fee. The user pays the same price they would on the booking platform directly.

Third, it lined up with my north star. I want to build products that help people connect. Group trips are exactly that. Four friends try to agree on dates, a house, and a budget over a seven-thread group chat. Most of the time the trip dies in that chat. If the product makes the trip actually happen, the friends spend the weekend together.

I told Maurice I was in. Then we spent the next two days emailing each other back and forth about what, specifically, we were going to build. I took a long time to write back. Something about the conversation felt like we were standing in a stream with gold dust running through our fingers. I just couldn’t see yet exactly where the gold was.

Maurice’s pitch in his original README was clean. AI trip planner that finds the 3 to 5 best stays for your group, ranked by real value, not just price. Not another search engine. A decision engine. Maurice was framing it as a ranking problem.

I pushed back gently. Ranking the best stay is the visible part of the pain. The invisible part, the part that actually makes group trips collapse, is the group not being able to agree on the stay.

So we moved the center of gravity from finding the best stay to helping the group decide on a stay together. That second framing turns it from a ranking algorithm into a small social product. The first commit that carries the pivot in code is mine on May 8th, Per-person budget filter against seeded listings.

Maurice is a sales guy. His skill set is selling, and he is good at it. He could have stayed in his lane, let me code, and worked the customer side of the wedge. He didn’t want to. He wanted to vibe-code, write real PRs, ship features, push commits with his name on them.

Some people would call this inefficient. A non-engineer in the codebase, AI-assisted code coming in over the wall, an engineer (me) reviewing every line. Strictly speaking, yes, it is slower than if I just owned the code outright. I have heard the stay in your lane version of this advice. I disagree with it.

My north star with this product is community. Building the product alongside someone whose aspiration is to grow into shipping code felt like the product and the team philosophy were already pointing the same direction. The actual problem was figuring out how to build the scaffolding so this could work without sacrificing the quality of what we ship.

What I built, concretely:

  • An AGENTS.md at the repo root. Conventions for AI-assisted contributions. No emojis or non-ASCII glyphs anywhere in code, scripts, commits, or PRs (the kind of thing that breaks CI on a runner pinned to ASCII stdout). Closes #N linkage enforced by CI on every PR. A two-comment PR review workflow so feedback loops stay tight.
  • Starter issues sized as pure utility functions. Maurice’s first three real PRs were formatMoney(), nightsBetween(), and splitPerPerson(). Small surface, easy to unit-test, no architecture decisions on the table. He could ship code that mattered without needing to hold the whole shape of the app in his head.
  • A sprint board with M1 / M2 / M3 / M4 milestones. The next thing to work on was always just “pick the next card from the M1 column.”
  • Pre-commit and CI hygiene tuned for AI-assisted code. Scans for build artifacts that shouldn’t be committed. Pattern-matching for things that look like secrets. The kind of paranoia you don’t bother with on a solo project, but that becomes necessary when your repo is partly written by a language model.
  • A dedicated onboarding doc named after Maurice’s GitHub handle, modweck.md, instead of a generic CONTRIBUTING.md. A file with his name on it was harder for him to skip.

I am not claiming any of this was generous. I wanted Maurice in the codebase, so I shaped the repo to let him code safely.

It worked. His PRs walked up the difficulty curve in a way I could not have planned exactly, but could plan the shape of. Three pure utilities on May 19th. Then trip-form UX polish. Then multi-select filters with real reviews. Then an Add-to-Trip modal. Then a full Trip Board page with the global tab bar. Then the Listing Detail view. Then the Invite Sheet for sharing the trip link. By May 22nd Maurice was shipping product-visible features at a pace that compounded with mine instead of against it.

Meanwhile I was free to handle the parts that needed one brain holding the whole shape. A universal Expo Router port over the weekend of May 18th and 19th, so the Next.js web MVP and the Expo iOS app share one codebase now. The Supabase schema with row-level security on trips, members, and listings. The affiliate URL rewriter with Stay22 as the primary provider and Travelpayouts as the fallback.

The gold finally crystallized on May 21st.

I renamed the product from Stayboard to fikastay. Fika is Swedish for the daily pause for coffee and conversation. Small group, no rush, real talk. I realized later that the metaphor doesn’t only describe the product. It describes how Maurice and I built it. Two people. No rush. Real conversation about what to ship next.

The two-day email thread back in May, where I kept writing slow replies because I couldn’t see the gold yet, was fika too. I just didn’t know it at the time.

Today, May 25th, fikastay.com is live. The Fika design language is on every screen. Landing page, trip form, results, trip board, listing detail, invite sheet. Maurice is shipping product features. I am shipping infrastructure. Some people would still call this arrangement inefficient.

The arrangement might be inefficient. But Maurice is one of the people building fikastay, and that is what I wanted.

You can check it out at fikastay.com.