<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Locallify</title>
    <description>The latest articles on DEV Community by Locallify (@locallify).</description>
    <link>https://dev.to/locallify</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4059775%2F88078d2f-2d96-438d-953f-ab575a3b8d2e.png</url>
      <title>DEV Community: Locallify</title>
      <link>https://dev.to/locallify</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/locallify"/>
    <language>en</language>
    <item>
      <title>How We Standardized on Next.js + Supabase to Ship Client Sites Fast at a 2-Person Agency</title>
      <dc:creator>Locallify</dc:creator>
      <pubDate>Fri, 21 Aug 2026 04:22:54 +0000</pubDate>
      <link>https://dev.to/locallify/how-we-standardized-on-nextjs-supabase-to-ship-client-sites-fast-at-a-2-person-agency-3hkd</link>
      <guid>https://dev.to/locallify/how-we-standardized-on-nextjs-supabase-to-ship-client-sites-fast-at-a-2-person-agency-3hkd</guid>
      <description>&lt;p&gt;Running a software studio with a 50/50 co-founder split and a growing roster of local business clients (clinics, hotels, retail, interiors) taught us one thing fast: you cannot afford a different stack for every project. Here's the setup we landed on at &lt;strong&gt;Locallify&lt;/strong&gt; after building sites for dental clinics, ENT specialists, diagnostics centers, hotels, and interior design studios — and why it's held up.&lt;/p&gt;

&lt;h2&gt;
  
  
  The core stack
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;Next.js&lt;/strong&gt; — server-rendered pages for SEO (critical for local businesses competing on Google), App Router, and easy deployment to Vercel&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Supabase&lt;/strong&gt; — Postgres + auth + storage, without us having to run our own backend for every client&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;TypeScript&lt;/strong&gt; — non-negotiable once you're maintaining 10+ codebases with one small team&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Tailwind CSS&lt;/strong&gt; — fastest path from a client's brand colors to a shipped page&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Vercel&lt;/strong&gt; — hosting, previews, and DNS in one place (paired with Hostinger/Namecheap depending on where the domain was originally bought)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The pitch to ourselves was simple: every client site is 80% the same problem (bilingual local business site, GBP integration, contact/booking forms, image-heavy content) and 20% unique. Standardizing the 80% let us spend our time on the 20%.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why Supabase over a custom backend
&lt;/h2&gt;

&lt;p&gt;Most of our clients don't need complex backends — they need:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;A way to store and update content without touching code (reviews, services, staff bios)&lt;/li&gt;
&lt;li&gt;Simple auth for the rare admin dashboard&lt;/li&gt;
&lt;li&gt;Reliable file storage for images (X-ray style before/after galleries, hotel room photos, etc.)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Supabase gives us all three with minimal setup, and because it's just Postgres underneath, nothing is a black box when a client's needs get more complex (we had one clinic ask for a fully offline patient management system — being on Postgres/SQL made that migration path far less painful than it would've been on a proprietary BaaS).&lt;/p&gt;

&lt;h2&gt;
  
  
  The parts that don't scale as cleanly
&lt;/h2&gt;

&lt;p&gt;&lt;strong&gt;Image optimization limits.&lt;/strong&gt; Running many client sites on Vercel's free/lower tiers means you hit image optimization quotas faster than you'd think, especially with photo-heavy sites (hotels, clinics with before/after galleries). We ended up rethinking hosting allocation per client rather than dumping everything under one account.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;API key security across projects.&lt;/strong&gt; With 13+ active client projects sharing patterns (same AI APIs, same Supabase conventions), it's tempting to reuse &lt;code&gt;.env&lt;/code&gt; values or copy-paste config between repos. We now treat every client's environment variables as isolated by default and audit before reuse — a leaked key on one clinic's project shouldn't be able to touch another client's data.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Bilingual content.&lt;/strong&gt; A lot of our clients serve Bengali-speaking audiences in Northeast India. Next.js doesn't have opinionated i18n out of the box the way some frameworks do, so we built our own lightweight pattern for bilingual pages rather than pulling in a heavier i18n library for what's usually 2 languages, not 20.&lt;/p&gt;

&lt;h2&gt;
  
  
  What this stack unlocks beyond "just a website"
&lt;/h2&gt;

&lt;p&gt;Because everything sits on the same foundation, it's been straightforward to layer on:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;strong&gt;AI-generated video ads&lt;/strong&gt; (Remotion for animation, Gemini for Bengali TTS) that pull content straight from the same Supabase tables powering the site&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;WhatsApp Cloud API integrations&lt;/strong&gt; for clinics that want automated booking/FAQ handling, without a separate backend&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;NFC tap-to-review hardware&lt;/strong&gt; — NTAG213 tags that redirect through a Next.js route into a Supabase-logged review flow — because the routing and data layer already existed&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;None of these were "planned" when we picked the stack. They became possible &lt;em&gt;because&lt;/em&gt; the stack was boring and consistent enough to build on top of without re-architecting per client.&lt;/p&gt;

&lt;h2&gt;
  
  
  The actual lesson
&lt;/h2&gt;

&lt;p&gt;If you're running a small studio serving many similar-but-not-identical clients, the biggest lever isn't picking the "best" tech — it's picking one good-enough stack and refusing to fragment it. Every one-off framework choice you make for a single client is a maintenance tax you'll pay for the life of that project, times however many clients you eventually have.&lt;/p&gt;




&lt;p&gt;&lt;em&gt;I run Locallify, a software studio and digital marketing agency based in Silchar, Assam, building web/app products and AI-powered creative services for local businesses. Happy to go deeper on any part of this stack in the comments.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>programming</category>
      <category>productivity</category>
    </item>
  </channel>
</rss>
