What 13 Episodes of Building in Public Taught Me

Closing a Chapter

The last episode ended with Santi sitting at a desk, clicking through SportsSync for the first time and finding gaps I hadn't seen. That was October. It's now April. In between, I've done more building than writing — the product has moved a lot, the series hasn't.

Before the next chapter, this post exists to do one thing: look back honestly at what these thirteen episodes got right, what they got wrong, and what someone else considering this path should take from it.

I won't pretend the series was a plan. It wasn't. Episode 1 was "I validated an idea with Claude and it was interesting, let me record it." Episode 13 was "I watched a user use the product and learned more in 45 minutes than in six months of assumptions." Everything between was me figuring out what kind of thing I was building and what kind of creator I wanted to be while building it.

What Survived From Episode 1

Looking at the original idea from March 2025: a cloud-based tool to overlay GPS telemetry on cycling videos, camera-agnostic, priced for individuals not pros. That core thesis is still the product today, thirteen months and many iterations later.

What survived:

• The premise that Garmin VIRB Edit left a gap and Telemetry Overlay doesn't fill it for casual users.
• The bet on web over desktop. Every instinct to "just build a Mac app" was resisted and that was correct.
• The positioning against existing incumbents — not trying to beat Telemetry Overlay on features, but beating it on accessibility and workflow.
• The idea that shorts for social are the wedge, not full-ride long-form.

What I got wrong or incomplete in episode 1:

• I framed the target user as "cyclists with a GoPro." The real target is more nuanced and I only learned that recently (episode 15 covers this).
• I underestimated how much the overlay quality itself — not the feature set — would be the product. It's not "a tool that adds data to video." It's "a tool that makes your ride look like a pro broadcast." Those are different products.
• I planned for AI highlight detection as phase 2. It's now phase 3 or maybe never. The product is useful without it; adding it solves a different problem than I originally thought.

One out of five major assumptions meaningfully wrong is probably a good hit rate for six months of building. But the ones I got wrong cost real time.

The Tools Journey

The series is also a timeline of AI tools moving fast. When I started, Lovable was the obvious choice for prototyping and Claude was the reasoning partner. By episode 12, I'd migrated to Claude Code and local development. The tools didn't just improve — the whole category shifted.

Some observations that might be useful:

AI-assisted prototyping tools are magic until they aren't. Lovable got me 80% of the way in days. The last 20% — two YouTube players on one page, GPX parser edge cases, production-grade testing — hit a wall I couldn't prompt my way through. That wall is real, and pretending it isn't wastes money. Knowing when to switch modes matters more than picking the "best" tool.

Claude as a thinking partner is underrated. The competitive analysis in episode 1, the persona work in episode 2, the architecture conversations I've had since — those compounded across the project. A good prompt to Claude at the right moment has saved me weeks of exploration. It won't make decisions for you, but it shortens the distance between "I have a vague sense something is wrong" and "I can articulate exactly what the problem is."

Local-first development won. Episode 12 was the turning point. Lovable was fast but opaque; Claude Code was slower to set up but transparent, testable, and mine. Five hundred tests. CI/CD pipelines. Semantic releases. None of that was possible in a hosted prototyping environment. At some point every real product outgrows the sandbox.

The Honest Ledger

Things I'm glad I did:

• Published episode 1 before the product existed. The waitlist emails from that single video still drive traffic today.
• Spent money on a designer for the logo (€35) instead of trying to AI-generate it. The brand holds up nine months later without modification.
• Said no to pricing on the landing page until the product justified it. Kept dodging that question felt uncomfortable but was correct.
• Did user research with Santi when I did. Too early would have been guessing; too late would have meant building on false assumptions for months longer.
• Killed my darlings in episode 5. The sections I loved but didn't need. The landing page is still closer to that stripped-down version than to anything I've added since.

Things I would do differently:

• Validate with real users earlier. Thirteen episodes between the idea and the first user test is too long. Even a rough Lovable prototype in front of someone in month 2 or 3 would have caught the vertical-video blind spot and the YouTube-dependency problem before I built around those assumptions.
• Trust the "camera-agnostic" framing sooner. I defaulted to "GoPro" in copy and examples for months because it's what I use. Most of my target users don't have a GoPro.
• Spend less time on the landing page before the product works. Episodes 3-5 were landing page iteration. In hindsight, a functional demo would have been more persuasive than a polished landing, and I could have built the demo first.
• Invest in retention mechanics earlier in the design. A tool used 1-4 times per month churns unless it actively re-engages the user. I didn't think about this until much later. It should have been on the whiteboard in episode 1.

The Numbers, Where I Can Share Them

I'm not going to pretend this is a venture-scale business. It isn't, and it's not trying to be. But some data points might be useful for anyone considering a similar path:

• Thirteen YouTube videos, modest view counts, organic subscribers in the low triple digits. Not a channel, a log.
• Two active users (me and Santi — both on ambassador access, neither paying yet).
• A landing page waitlist that trickles signups weekly without paid promotion.
• Infrastructure costs under €50/month. Still well below break-even on founder time, obviously profitable on infrastructure alone with any real user base.
• Total out-of-pocket spend across thirteen months: around €1,500 including Lovable subscription, Claude Code, Fiverr designer, domain, hosting, the lot. Not nothing, but not much for a functional SaaS product.

The costs of building a thing like this in 2026 are genuinely lower than they were in 2023. The hard part is no longer "can a solo builder ship a SaaS." It's "can a solo builder find the customers for their SaaS." That problem has not gotten easier.

What Building in Public Actually Taught Me

The cliché is that you build in public for marketing. That's not quite right, at least not for me. The real benefits were different:

Forced clarity. Recording a video about what I was going to do that session meant I had to know what I was going to do that session. Half the decisions in this project happened in the five minutes before hitting record, when I realized I couldn't explain my plan out loud.

Community feedback as free consulting. Comments on the videos caught real issues — the before/after slider idea in episode 4 came from a commenter, not from me. The "you can't browse the web" correction in episode 2 came from a commenter. People who watch your process will hand you insights that would cost thousands from a consultant.

Accountability without pressure. Knowing someone was waiting for the next episode kept me moving on weeks I might have otherwise stalled. Not "I must publish or I fail" pressure — more like "I have a conversation in progress and it's my turn to say something."

A portable record. When I moved from Lovable to Claude Code, when I explained SportsSync to Santi, when I pitched it to Edu and Marc — I had thirteen videos documenting how we got here. That's a credibility asset that doesn't exist for people who build silently.

The cost is real, too. Recording and editing takes time. Not every session is interesting enough to publish. You develop a nagging "is this worth filming" voice in your head that can distort decisions. Some episodes in this series exist partly because I felt I owed an update, not because the content was strong. That's the tax of the format.

What's Next

The product is further along than the series has documented. Since episode 13, there's been Instagram direct publish, Stripe subscription tiers, a full 30-day expiration model, internationalization, a proper blog, a working upload pipeline. Most of the technical MVP is shipped.

What's pending is polish (overlay quality to a professional standard), retention infrastructure (the Strava webhook loop that pings users when they have a new ride to edit), mobile scrubber UX that actually works on a phone, and Strava's production API approval.

And — critically — a positioning shift I didn't see coming, which happened in a single WhatsApp conversation with a cycling creator and reframed who SportsSync is actually for. That's the next episode.

Thirteen Episodes, One Sentence

If I had to compress the lesson of this series into one sentence for someone considering the same path:

The product you end up building is almost never the product you plan in episode 1, and the faster you get real users in front of real builds, the less time you waste discovering that.

Everything else is details.

The Series Isn't Ending — It's Starting a New Arc

I called episode 13 the "series conclusion" because it felt like one. Actual user research, real feedback, a defensible product. But the product isn't the same one I was building when I wrote that conclusion. The market repositioned itself on me between October and April, and the next phase is going to be about responding to that.

If you've been reading since episode 1, thank you. If you're just arriving — there's a backlog. Start wherever feels interesting.

The next episode is about what happens when someone you respect in your target market looks at your product and tells you, politely, that your biggest competitor ships inside the camera your users already own.

See you there.