Jorge Martinelli

May 07, 2026 • 6 min read

Building a Social App for LATAM as a Solo Founder: What Actually Worked

The real decisions behind Peekr — stack choices, designing for Spanish and Portuguese markets, building an algorithmic feed without a data team, and the honest tradeoffs of going solo.

Building a Social App for LATAM as a Solo Founder: What Actually Worked

The real decisions behind Peekr — stack choices, designing for Spanish and Portuguese markets, building an algorithmic feed without a data team, and the honest tradeoffs of going solo.

I've been building Peekr for about six months. It's a social app for movies and TV shows — think Letterboxd meets a social graph, designed specifically for Latin America. Users rate content, follow friends, build watchlists, and get recommendations based on what people they actually know are watching.

I'm building it alone. One founder, no co-founder, no team. Everything from the Flutter app to the Supabase backend to the Next.js web app to the automated content pipeline — all of it. This article is about the decisions that actually mattered, the ones I'd make the same way again, and the ones I wouldn't.

Why LATAM, and why that changed everything

Most social apps treat Latin America as an afterthought — an English product with a Spanish translation bolted on afterward. Localization as a checkbox. I wanted to build something where Spanish and Portuguese were first-class citizens from day one, not just in copy but in content, in cultural references, in the algorithm.

This decision had real technical consequences. I use es-419 (Latin American Spanish ISO code) everywhere TMDB supports it, not es-ES. I built a multilingual article system from the start — every piece of content is authored in three languages simultaneously. The routing is /es/, /en/, /pt/ with proper hreflang alternates and JSON-LD structured data for each. Google treats them as separate pages targeting different markets.

It also changed my content strategy entirely. The Hollywood trade press (Variety, THR) has zero search demand in LATAM. Nobody in Argentina searches for "Gwyneth Paltrow goop discount." They search for "El Eternauta qué ver después" or "filmografía Jackie Chan." I had to build my content pipeline around that reality, not copy what English-language apps do.

The stack: Flutter + Supabase + Next.js

I chose Flutter for the mobile app. In 2024, this is still a somewhat contrarian choice — React Native has more ecosystem, more hiring pool, more Stack Overflow answers. But I'd used Flutter before and I knew I could ship faster alone. One codebase for iOS and Android, hot reload, excellent widget system. The productivity advantage of knowing a framework deeply beats the theoretical advantages of a more popular one when you're a team of one.

Supabase was the clearest decision I made. Postgres at the core means I can write real SQL — window functions, CTEs, complex joins — without fighting an ORM abstraction. Row Level Security handles auth at the database level. Edge Functions (Deno) let me run server-side logic without managing infrastructure. Realtime subscriptions power the social feed. The entire backend is one project, no microservices, no containers to orchestrate.

The web app is Next.js on the App Router, deployed on Vercel. Mostly for SEO — the mobile app is the primary product, but a crawlable web presence with proper meta tags, OpenGraph, and structured data is how you get indexed by Google before you have enough backlinks to matter. Actor pages, title pages, article pages — all server-rendered, all indexed.

Building an algorithmic feed without a data team

The social feed in Peekr is the hardest engineering problem I've worked on as a solo developer. The goal is to surface content that's genuinely interesting — not just chronological, not just popular, but personalized to your specific social graph and taste profile.

I built it in Postgres. A single SQL query with a weighted scoring function: recency, engagement velocity, social graph proximity (do you follow the person who rated this?), genre affinity, and a novelty penalty to avoid showing the same titles repeatedly. The query runs in under 100ms for most users. No Redis, no separate recommendation service, no ML pipeline.

Is it as good as what Netflix has? Obviously not. Is it good enough to be useful and feel personal? Yes. The insight is that for a social app at early scale, the social graph signal is so strong that you don't need sophisticated ML — if your friend who has similar taste just watched something and rated it 8/10, that's more valuable than any collaborative filtering model.

The content pipeline: automating what a team would do

One person can't produce enough content to keep a social platform active. I built an automated pipeline using Supabase Edge Functions, Gemini 2.0 Flash, and pg_cron.

The daily brief system sends me three content options every morning via Telegram. I approve one, it generates a full Instagram carousel with AI-written copy and poster images, and schedules it for publication. No manual writing, no manual posting. The approval step keeps me in the loop without creating a bottleneck.

For SEO, I built a separate content queue: actor filmographies, "what to watch after X" articles, each generated in Spanish, English, and Portuguese simultaneously. Two articles publish automatically every day, backdrops from TMDB as hero images (landscape format — poster crops look terrible in article headers), internal links to every actor and title page on the site. The whole system runs without me touching it.

What I'd do differently

I underestimated how long SEO takes. The site has been indexed for six weeks and organic traffic is still minimal — mostly branded searches. The Google sandbox is real, and there's no shortcut. I should have started publishing content from month one, not month five.

I also spent too long building features before validating retention. The social graph, the algorithmic feed, the personality test — all of it was built before I had enough users to know if any of it was working. A solo founder's biggest risk is building in isolation. I should have been more aggressive about getting real users earlier, even with a rougher product.

The honest answer about going solo

It's slower than having a team. Obvious. Less obvious: it's also more focused. Every hour I spend on a feature is an hour I'm not spending on something else, which forces brutal prioritization in a way that larger teams often avoid. There's no "we could build both" — there's only "which one actually matters."

The tools available to solo developers in 2025 are genuinely different from five years ago. AI coding assistants, managed backend infrastructure, automated content pipelines — the leverage per person has increased dramatically. I'm not sure Peekr would have been buildable by one person at this scope three years ago.

Whether it works is still an open question. But it's shipping, it's indexed, and it's getting better every day — which is more than most side projects can say at month six.


Jorge Martinelli is the founder of Peekr, a social app for movies and TV shows built for Latin America. You can follow the build on Peerlist.

Join Jorge on Peerlist!

Join amazing folks like Jorge and thousands of other builders on Peerlist.

peerlist.io/

It’s available... this username is available! 😃

Claim your username before it's too late!

This username is already taken, you’re a little late.😐

0

4

0