Building in the Void: What Public Teardowns, Ruthless Cuts, and a Caribbean Island Taught Me About Shipping

Founder of PoquitoTalk • Built in Public for the RevenueCat Shipaton 2026

There is a sanitized version of the "Building in Public" fairy tale that founders love to perform on social media.

In that version, you tweet a screenshot of a rough wireframe, wake up to hundreds of eager DMs, launch to explosive App Store downloads, and casually post an upward-curving revenue graph labeled "Humbled and grateful."

That was not my experience.

Over the past month, I have been building PoquitoTalk - a real-time Spanish voice translation engine and verified service directory designed specifically for expats, boat captains, and island tradespeople in Bocas del Toro, Panama - as part of the RevenueCat Shipaton 2026.

I built it in public from day one. I shared my raw, unvarnished paywall designs on X. I posted unedited mobile workflows to local community forums. I documented my technical architecture, opened up my codebase, and asked for brutal, unsparing feedback.

What I got wasn't viral applause.

Instead, I got something vastly more valuable: ruthless teardowns that completely dismantled my initial product assumptions, forced me to murder features I loved, exposed the emotional toll of the "post-launch void," and ultimately forged a resilient, community-grounded product.

If you are currently building a product in public - or gearing up to enter a high-stakes hackathon - here is the unpolished reality of what the journey actually looks like when you peel back the social media filters.

1. The Island Reality Check: Where Product Theory Goes to Die

When I first sat down to conceptualize PoquitoTalk, my mental model was clean, academic, and completely wrong.

Living in Bocas del Toro - an archipelago off the Caribbean coast of Panama - you quickly learn that local commerce does not happen over email, website booking engines, or even SMS. There are no highways between the islands. You travel by wooden water taxi (panga), depend on rainwater collection tanks, and rely on local trades to keep boat engines and A/C units alive in humid salt air.

In Panama, 100% of local trade logistics happen through WhatsApp voice notes.

Local boat captains dodging waves or carpenters perched on roof frames rarely type or read long WhatsApp texts. If you send a textbook Spanish paragraph generated by Google Translate, you create instant friction:

1. The boat captain has to pull over, put on reading glasses, and squint at tiny text in bright tropical glare.
2. If they reply, they send a five-second, rapid-fire Panamanian voice note ("¡Buenas! Voy saliendo de Almirante, llego en veinte...") recorded over an outboard engine roar.
3. If you only know classroom Spanish, you are completely stranded.

[The Developer Assumption] ─────► "People just need a text translation box."
 "They can copy-paste translated Spanish into WhatsApp."
 
[The Caribbean Reality] ─────► Nobody reads text while steering a boat.
 Voice is culturally non-negotiable.
 If the receiving person has to download an app, it's dead on arrival.

Building in public forced me to confront this reality on Day 1. When I quietly floated early text-based ideas to fellow expats, the feedback was unanimous: "If it doesn't send real WhatsApp voice notes, and if the boat captain has to download anything, nobody here will use it."

That single community conversation completely pivoted the project before I wrote another line of UI code. We killed the generic text interface and engineered:

• 1-Tap WhatsApp Audio Generation: Converting English thoughts directly into native .mp3 voice note files featuring authentic Panamanian dialect phrasing.
• The Zero-Install Web Walkie Bridge (/talk): When you message a contractor, you can share a lightweight link. The contractor opens it directly in their mobile browser - no App Store download, no login, no friction - taps a large green button, and speaks in Spanish. Their audio is transcribed, translated back to English, and delivered to your phone in under 400ms.

Public feedback prevented me from building a textbook app nobody in the real world would touch.

2. The Peer-to-Peer Teardown: Learning While Teaching

When you post updates on X (@DorienVibecodes) as a solo founder, you don't always get hundreds of replies. Most days, you get a handful of likes and silent impressions.

┌───────────────────────────────────────────────────────────────┐
│ THE BUILDING IN PUBLIC SPECTRUM │
├───────────────────────────────┬───────────────────────────────┤
│ The Social Media Myth │ The Grounded Reality │
├───────────────────────────────┼───────────────────────────────┤
│ • 5,000 likes on every mockup │ • 4 likes, but 1 deep critique│
│ • Flattering vanity metrics │ • Direct peer-to-peer insights│
│ • Performed perfection │ • Two builders teaching each │
│ • Surface-level cheerleading │ other through public code │
└───────────────────────────────┴───────────────────────────────┘

But then, someone with real expertise stops by.

I had shared my raw, initial RevenueCat paywall designs. I thought they were decent. I had picked a clean card layout, mapped out our subscriptions, used our app's warm terracotta brand color on the buttons, and assumed the value would speak for itself.

An experienced builder named Jay saw the designs and tore them apart with surgeon-like precision.

It wasn't hostile critique; it was an incredible peer-to-peer exchange where both of us were actively learning from the nuances of mobile UX psychology. He taught me deep monetization patterns, and in dissecting my edge cases, we both walked away with sharper mental models.

He pointed out five deep, counter-intuitive flaws that had completely eluded me:

Lesson 1: The Context Dichotomy (Onboarding ≠ In-App Gate)

In our first iteration, whether a user had just finished onboarding or had just hit their daily quota while trying to hail a water taxi, they saw the exact same full-screen modal.

Jay pointed out that these two mindsets are radically different:

• The Onboarding User is exploring. They need value reassurance, trust anchors, and an airy narrative.
• The In-App User is in a hurry. They are trying to complete a live task. Forcing a full-screen onboarding narrative onto them causes intense irritation.

The Fix: We decoupled our monetization into two separate React Native components:

1. SoftOnboardingPaywall.tsx: A warm, full-screen canvas (#FAF8F5) featuring our mascot Poquito, a 4-benefit value grid, and soft 7-day trial framing.
2. PaywallModal.tsx: A compact, non-intrusive bottom-sheet drawer that slides up over their active workspace, preserving screen context and offering a fast 1-tap checkout.

📷 [Image Embed Note for HackerNoon Editor]: Drag and drop paywall_evolution_before_after.png here.

Figure 1: The Before and After evolution - from a cluttered single modal to an intentional dual-architecture system.

Lesson 2: The "Unique CTA Color" Rule

PoquitoTalk's palette is rooted in Caribbean terracotta (#964824), sage green (#059669), and warm linen. Naturally, I styled our primary purchase button in terracotta.

Jay’s insight was immediate: If your purchase button shares a color with your badges, icons, and tags, it competes with the rest of your app for visual dominance.

At the moment of conversion, there must be zero cognitive hesitation about what the primary action is.

// src/components/SoftOnboardingPaywall.tsx
// We introduced an isolated accent that exists nowhere else in the app:
const styles = StyleSheet.create({
 mainCtaButton: {
 width: '100%',
 backgroundColor: '#4F46E5', // Bright Royal Indigo - 100% unique in the app
 paddingVertical: 15,
 borderRadius: 22,
 alignItems: 'center',
 justifyContent: 'center',
 shadowColor: '#4F46E5',
 shadowOffset: { width: 0, height: 4 },
 shadowOpacity: 0.35,
 shadowRadius: 10,
 elevation: 4,
 },
 mainCtaText: {
 fontSize: 16.5,
 fontWeight: '800',
 color: '#FFFFFF',
 letterSpacing: -0.2,
 },
});

Against our warm cream background, this Royal Indigo button commands 100% visual focus. It cannot be mistaken for a category pill or a decorative tag.

Lesson 3: The "Never Expires" Loss-Aversion Anchor

We offer a 50 Credits Pack for $4.99 for tourists and backpackers who don't want recurring monthly subscriptions. Our initial card read:

50 Credits Pack - $4.99 once

Jay pointed out that pay-as-you-go buyers suffer from acute loss aversion: "Will these credits vanish if I don't use them all before my island vacation ends next week?"

We added two simple words in an emerald green badge: "Never expires". That tiny guarantee reframed the pack from a ticking clock into a permanent island tool they can keep forever.

Lesson 4: The Linguistic Shift ("Try it first")

Underneath our main button, our secondary dismissal link originally read:

"Or continue with Free Version"

Words carry heavy psychological baggage. Stating "Free Version" explicitly introduces the feeling of downgrading to a second-class experience, while planting the seed: "Wait, if there's a free version, why should I even bother with the trial?"

We replaced it with three confident words:

"Try it first"

It removes the downgrade stigma, frames action over status, and fits cleanly onto small viewports without wrapping.

Lesson 5: Escape Hatch Discipline

Our early paywalls had a top (X) close button and a bottom dismissal link. Two competing exits right beside the offer create decision fatigue; users subconsciously search for the fastest exit instead of considering the value.

We streamlined our exit hierarchy, keeping a single subtle dismissal path while maintaining a clean, ethical user experience.

📷 [Image Embed Note for HackerNoon Editor]: Drag and drop onboarding_vs_settings_paywall_comparison.png here.

Figure 2: Side-by-side comparison of the full-screen onboarding paywall vs. the compact in-app drawer.

If I had kept my designs private in a folder on my laptop, I would have shipped a leaky, confusing paywall. Sharing it openly and engaging with a single fellow builder rewrote our entire conversion foundation.

3. Killing Your Darlings: The Hardest Cut

The most painful discipline in building in public is not accepting critique - it is saying no to features you personally love.

As an expat living in Panama, I fell in love with the colorful nuances of Panamanian Spanish. I spent days fine-tuning prompts to capture hyper-local street slang (jerga): expressions like "¿Qué xopa, fren?" (What's up, friend?), "tas en panga" (you're out of luck), "arrancar" (to party), and regional island idioms.

In our early builds, I built an entire dialect selection fork right into the main translation interface:

• Option A: Polite Panamanian Spanish ("¡Buenas! Estimado, necesito coordinar un viaje...")
• Option B: Deep Street Slang ("¡Xopa fren! Tírame una lancha pa' Carenero rápido...")

I was immensely proud of this feature. Technically, it was brilliant.

┌───────────────────────────────────────────────────────────────┐
│ THE FOUNDER'S DIALECT DILEMMA │
├───────────────────────────────┬───────────────────────────────┤
│ What I Wanted to Ship │ What Users Needed │
├───────────────────────────────┼───────────────────────────────┤
│ • 2-way Slang Switcher │ • 1 clean, reliable button │
│ • Street Slang vs Polite │ • Universal, polite Spanish │
│ • Complex cognitive choice │ • Zero risk of offending │
│ • Slower shipping velocity │ • Fast 1-tap dispatch │
└───────────────────────────────┴───────────────────────────────┘

But when I put the prototype into the hands of real testers, the crack appeared immediately.

Users stared at the dialect toggle with hesitation. An American expat trying to hire a licensed electrician to inspect a smoking solar inverter doesn't want to accidentally address him with aggressive street slang. They were terrified of saying the wrong thing and looking disrespectful.

The feature didn't create delight - it created cognitive overload and hesitation at the exact moment they needed fast utility.

I had to kill it.

I removed the dialect selector completely and standardized the entire engine on warm, polite, natural Panamanian Spanish. It was a bitter pill to swallow because I had poured hours of passion into that prompt engineering. But getting V1 out the door for the Shipaton required ruthlessly cutting complexity.

As solo builders, our ego often tries to prove "how smart we are" by packing twenty intricate features into an MVP. Building in public acts as a mirror: it forces you to strip away your ego and focus on what actually serves the user.

4. The Post-Launch Void: The Hardest Founder Mindset

There is a moment in every indie project that nobody prepares you for: the silence immediately after you ship.

You spend sleepless nights polishing the code. You navigate Google Play Console reviews, configure RevenueCat offerings, test Stripe webhooks, hook up offline SQLite and Firestore caching, and build automated verification scripts.

You push the release to production. The app is live on the Google Play Store. The web funnel (poquitotalk.hero-apps.com) is deployed.

And then... nothing.

No flood of downloads. No sudden surge of payments. No spontaneous viral explosion.

[Day 1-15: The Build Rush] ────► High adrenaline, coding flow, excitement.
[Day 16: The Release] ────► "We're live on Google Play!"
[Day 17-25: The Void] ────► Silence. No instant downloads. Self-doubt creeps in.

This is the "Post-Launch Void." And when you are building in public, that void feels doubly loud.

Because your journey is public, your internal voice whispers: "Everyone sees that you shipped, and everyone sees that you don't have thousands of users yet." It is tempting to feel like a failure, pack up the repo, and move on to the next shiny hackathon idea.

The hardest part of building in public isn't writing the code or taking the critique. It is having the psychological stamina to keep promoting, iterating, and believing in a product when you feel like you are shouting into an empty canyon.

I reminded myself of why I started: PoquitoTalk was never meant to be a generic global B2C app with 500,000 random downloads. It was built to solve an acute, painful communication breakdown in a real physical community.

And if people on the island aren't randomly stumbling across the app on Google Play, that doesn't mean the product is flawed - it means the distribution channel has to evolve.

5. The Distribution Pivot: From App Store Hope to Island B2B

If waiting for individual expats and tourists to search "Panama voice translator" on Google Play wasn't working, what would?

I looked around Bocas del Toro at where the problem actually begins:

• A tourist arrives at a waterfront eco-lodge or boutique hotel on Isla Solarte.
• They check in, sit down at the lounge, and want to book a boat to Starfish Beach, find a dinner reservation, or schedule a massage.
• The hotel receptionist is constantly answering the same logistical questions and writing down WhatsApp numbers on scraps of paper.

This realization sparked our next strategic pivot: The Local B2B Partner Ecosystem.

 ┌─────────────────────────────┐
 │ Bocas Hotels & Restaurants │
 └──────────────┬──────────────┘
 │ (Host Menu & Services)
 ▼
┌──────────────────┐ ┌─────────────────────────────┐ ┌──────────────────┐
│ Visiting Tourist │ ────────► │ PoquitoTalk Web / App │ ◄──────── │ Local Trades & │
│ (Scans QR Code) │ │ - Digital Hotel Menu │ │ Boat Captains │
│ │ │ - Verified Services │ │ (0-Install Audio)│
│ │ │ - 1-Tap WhatsApp Voice │ │ │
└──────────────────┘ └─────────────────────────────┘ └──────────────────┘

Instead of chasing individual B2C app installs in a vacuum, we are taking PoquitoTalk directly to local hotels, hostels, and waterfront restaurants:

1. Digital Menu & Amenity Integration: We are onboarding restaurant and hotel menus directly into the PoquitoTalk service directory. Guests can browse local menus in English, understand local seafood dishes, and order with zero confusion.
2. The Hotel Welcome Package: When guests check in, hotels provide a branded QR code linked to our web funnel (poquitotalk.hero-apps.com).
3. Pre-Bundled Travel Passes: Hotels can offer a 7-Day Travel Pass ($4.99) as a curated concierge amenity, giving guests 1-tap WhatsApp voice translation and access to verified, reliable boat captains from the minute they step onto the dock.

By anchoring the product to physical island hubs, we transform PoquitoTalk from an "invisible utility in the App Store" into an essential piece of local island hospitality infrastructure.

6. The Solo Founder’s Build-in-Public Diagnostic Checklist

If you are currently competing in a hackathon like the RevenueCat Shipaton or building an indie product in public, run your journey through these five diagnostic questions:

Final Thoughts: The True Measure of Shipping in Public

Building in public is not a marketing silver bullet. It will not magically guarantee that your app goes viral on launch day.

What it does do is strip away your illusions.

It forces you to listen to real people who don't care about your tech stack. It connects you with generous peers who will spot flaws in your paywall before you burn through your runway. It holds your feet to the fire when you want to procrastinate by adding ten more features. And it gives you the conviction to push through the post-launch void and find the distribution channels that actually work.

PoquitoTalk is live today on Google Play and on the web at poquitotalk.hero-apps.com.

It isn't perfect. We are still learning, still iterating, and still talking to our community every single day.

And that is precisely the point.

Dorien Van den Abbeele is an indie developer building PoquitoTalk for the RevenueCat Shipaton 2026. Follow the real-time build, code breakdowns, and island experiments on X at @DorienVibecodes.