Zero to MVP: the stack I bet on
Building Pidiga as a small team meant every tool had to earn its place — ship fast, stay cheap, and run with almost no ops. Here's the stack I bet on, and why.
The constraint
When you're building an MVP with a tiny team, the enemy isn't a hard technical problem — it's everything that isn't the product. Servers to patch, queues to babysit, dashboards to wire together. So I picked a stack with one rule: managed where it doesn't differentiate us, owned where it does. Spend the engineering on Pidi; rent the rest.
Frontend — React on Vercel
React was the obvious choice for the seller app and storefront — huge ecosystem, easy to hire for, and component reuse between the dashboard-replacement chat UI and the customer-facing store. Vercel sits under it: push to git, get a deploy. Preview URLs per branch, edge caching, image optimization, zero servers to think about. For a team that needs to ship multiple times a day, removing the deploy step entirely is worth a lot.
Data & backend — Supabase
Supabase gave me a real Postgres database — not a black box — plus auth, file storage, and realtime out of the box. That combination is the whole backend for an MVP. Row-level security means the data rules live in the database instead of scattered across application code, and realtime subscriptions make a chat-driven product feel live without me hand-rolling websocket infrastructure. When we outgrow a managed feature, it's still just Postgres underneath — no rewrite, no lock-in panic.
The edge — Cloudflare
Cloudflare is the front door: DNS, CDN, and a security layer that costs nothing to turn on. Beyond that it's where the glue runs — Workers for lightweight edge logic and webhook handling close to the user, R2 for object storage without egress fees. Pushing routing, caching, and the cheap-but-frequent work to the edge keeps the core app small and the bills predictable.
The runtime — Node, leaning Deno
Server-side logic runs on Node — same language as the frontend, so context-switching is minimal and code is shared across the stack. I lean on Deno where its strengths fit: native TypeScript, a sane permissions model, and a clean fit with edge functions. One language end to end means a small team moves fast without juggling ecosystems.
Meeting customers where they are — direct Meta integration
This is the piece that makes Pidi feel different. Sellers and their buyers already live on WhatsApp and Instagram — so instead of forcing them into yet another app, I integrated directly with Meta: the WhatsApp Cloud API and the Instagram Graph API.
No third-party messaging middleman taking a cut and adding latency. Pidi receives messages straight from Meta's webhooks, runs the conversation, and replies on the same thread — order updates, product drops, support, checkout. Going direct means lower cost per message, full control of the experience, and access to features the moment Meta ships them.
None of this is exotic. That's the point. A boring, managed, well-understood stack is exactly what lets a small team spend its scarce attention on the only thing that matters at MVP stage: does Pidi actually run the seller's business? Everything else is rented infrastructure, and it should stay that way for as long as possible.