DEV Community: Arjun

[Boost]

Arjun — Sun, 12 Jul 2026 15:32:33 +0000

Jul 12

I Built an AI Speech Coach That Remembers Every Attempt You've Ever Made — Here's What Supermemory Local Actually Bought Me

4 min read

I Built an AI Speech Coach That Remembers Every Attempt You've Ever Made — Here's What Supermemory Local Actually Bought Me

Arjun — Sun, 12 Jul 2026 15:32:23 +0000

I wanted to build something that actually accumulates a picture of you over time. That's 1in100, a mobile-first speaking practice app I built for the Supermemory Local hackathon: pick a category, spin for a random topic, choose your difficulty, and speak for 15 to 60 seconds. Simple enough. The interesting part is what happens on your third attempt in the same category, not your first.

The comparison that shaped the whole build
There's an existing app, Magnetic, that does random topic + timer + per-session scoring really well. That's a good baseline. It's not a differentiator. If I built the same thing with a nicer UI, I'd have a worse version of something that already exists.
The actual question I kept coming back to: what can a memory layer do here that a single stateless API call can't? Not "your confidence score is 72 today." That's just a number. The interesting version is: "every time you get a finance topic, you hedge about three times more than your average, and here's the exact phrase you used last time and the time before that." That requires real retrieval across sessions. That's the whole reason this is built on Supermemory Local instead of just calling an LLM once per attempt and calling it a day.
How the loop actually works
Every completed round goes through a real pipeline, not a mockup:

Recording: browser MediaRecorder, captures the full clip for your chosen duration
Transcription: Groq Whisper (whisper-large-v3-turbo), transcript back in a few seconds
Scoring: words-per-minute from the transcript, a filler-word regex pass, and a Groq call (llama-3.3-70b-versatile) judging hedging language and structure
Memory write: the full round, topic, category, duration, scores, transcript, timestamp, gets written to Supermemory Local as a structured event
Memory retrieval: before showing you results, the app searches your past attempts in the same category and looks for a real, specific, repeatable pattern, not a vibe

That last step is where the actual product lives.
The rule I refused to cut: never invent a pattern
Here's the thing about LLM-generated "insights": they're extremely good at sounding confident whether or not there's anything real underneath. If I let the model generate a callback every single time regardless of whether the retrieved memory actually supported one, I'd have built a very convincing lie generator, not a memory feature.
So the hard rule from day one: if there's no real pattern across at least two past attempts, the app says exactly that, plainly, and never fabricates a callback to fill the silence. This was the one thing on my cut list I marked as non-negotiable, everything else, the leaderboard, auth polish, a second speaking mode, was allowed to slip if time ran out. This wasn't.

Getting the pattern-detection prompt itself right took a few iterations. Early versions produced technically-true but useless output, "you tend to hedge sometimes," which is the kind of feedback that's forgettable because it isn't falsifiable or specific. The fix was forcing the retrieval prompt to demand a single, quotable, specific behavior, an exact repeated phrase, an exact structural habit, tied to which past attempts it showed up in, or nothing at all. Specific-or-silent, no middle ground.
What Supermemory Local specifically bought me here
A few things that would've been genuinely painful to hand-roll:

Structured event storage without standing up my own vector DB and retrieval pipeline. I write a structured JSON event per round, category, topic, transcript, scores, timestamp, and query it back by category later. That's the whole integration surface.
Local-first meant zero latency anxiety during development. No round-trip to a hosted service while I was iterating on the retrieval prompt dozens of times in a single afternoon.

It made the "no pattern found" case cheap to implement correctly, instead of every past attempt at any cost, because the retrieval step is fast enough that checking "do we actually have 2+ relevant past events" before even calling the pattern-generation prompt was a trivial gate to add, not an expensive one to skip.

What I'd tell someone starting the same build
Verify constantly, and don't trust a green checkmark. The single most useful habit in this build was refusing to accept "it should work" as a substitute for actually opening the database and looking at a real row, or actually reading the real transcript output instead of assuming the pipeline behaved. More than once, a "this is done" turned out to be infrastructure working in isolation, a seed script inserting fake rows, a test confirming a table existed, without the actual end-to-end user flow ever being exercised. The bugs that matter hide exactly there.
And build the failure state on purpose. Whisper will occasionally return grammatically coherent nonsense from mumbled or noisy audio, not an empty string, actual plausible-sounding fabricated sentences. If you only guard against empty transcripts, that kind of hallucinated input sails straight through to scoring and memory, and it's worse than a missing guard because it looks like a legitimate result instead of a caught error.
Try it

Demo video: https://youtu.be/soZ6ogp4JgQ?si=O5Z2nMClBA2NRDP5
Repo: https://github.com/CoderOtakuX/1-in-100

Built with Next.js, Groq (Whisper + Llama 3.3), Supermemory Local, Supabase, and Clerk, over the course of a very caffeinated few days for the Supermemory Local hackathon.
If you're building anything where "does this tool remember me" is a real product question and not just a nice-to-have, I'd genuinely recommend starting with the failure case first, decide what "no real answer" looks like before you build what "a real answer" looks like. It's much harder to retrofit honesty into a feature after the fact than to design for it from the start.

🍌 Meet Nano Banana 2: Google's Newest Image Model (Gemini 3 Flash Image) + Must-Try Prompts

Arjun — Tue, 03 Mar 2026 04:02:06 +0000

If you've been using Google's Gemini App for image generation lately, you might have noticed a serious upgrade under the hood. The original Nano Banana and Nano Banana Pro models have officially stepped aside to make way for the new king of the jungle: Nano Banana 2.

Officially known as Gemini 3 Flash Image, this state-of-the-art model isn't just a minor patch—it's a massive leap forward in how we generate, edit, and compose images. Whether you're a frontend dev looking for quick placeholder art, a game designer needing asset inspiration, or just an AI enthusiast, Nano Banana 2 is worth your attention.

Here’s a breakdown of what makes it special, along with some prompts you absolutely need to try.

🚀 What’s New in Nano Banana 2?
The biggest shift with Nano Banana 2 is its versatility. It's not just a standard text-to-image generator anymore. It handles three core workflows:

Text-to-Image: Faster generation with significantly higher fidelity and prompt adherence. It understands complex spatial relationships much better than its predecessor.

Image + Text-to-Image (Editing): You can now seamlessly edit existing images. Want to change the background of your headshot or add a cyberpunk aesthetic to a photo of your desk? It handles it beautifully.

Multi-Image-to-Image (Composition & Style Transfer): This is the killer feature. You can feed the model multiple images and ask it to combine them. For example, you can upload a rough wireframe sketch and a screenshot of your favorite website, and ask it to generate a high-fidelity UI mockup combining the two.

(Pro Tip: If you're on a paid tier like AI Plus, Pro, or Ultra, you can generate an image with Nano Banana 2, click the three-dot menu, and hit "Redo with Pro" to tap into the heavier Nano Banana Pro model for even more refined details!)

🛠️ Must-Try Prompts for Developers & Creators
Ready to take it for a spin? Here are a few prompts designed to test the limits of its new capabilities:

1. The UI/UX Wireframe Concept (Text-to-Image)
Prompt: A high-fidelity UI mockup for a modern, dark-mode weather application on a mobile phone. The design should feature glassmorphism, glowing neon blue and purple accents, and a highly detailed 3D weather icon in the center. Clean typography, minimal layout.

2. The Mascot Generator (Text-to-Image)
Prompt: A 3D isometric render of a cute robotic red panda wearing a tiny developer hoodie, sitting at a futuristic desk typing on a glowing mechanical keyboard. Soft studio lighting, highly detailed, vibrant colors.

3. The "Fix My Desk" Edit (Image + Text-to-Image)
(Upload a messy photo of your current workstation)

Prompt: Keep the laptop and monitors exactly where they are, but transform the messy room behind them into a serene, minimalist Japanese Zen garden with a bamboo wall and soft sunlight streaming in.

4. The Style Mashup (Multi-Image-to-Image)
(Upload Image A: A photo of your pet. Upload Image B: A screenshot of an 8-bit retro video game)

Prompt: Combine these two images. Recreate the animal from the first image entirely in the retro, 8-bit pixel art style of the second image, maintaining the exact color palette of the second image.

Wrapping Up
Nano Banana 2 (Gemini 3 Flash Image) feels like a tool built for builders. The multi-image composition alone opens up massive possibilities for rapid prototyping and mood-boarding.

Have you tried the new model yet? Drop your favorite prompts or the weirdest generations you've gotten so far in the comments below! 👇

I Built a Social Platform Where You Can Post in Hindi and Someone in Tokyo Reads It in Japanese — Here's How

Arjun — Mon, 23 Feb 2026 03:28:07 +0000

🌐 The Problem That Kept Me Up at Night

Picture this.

You discover a Reddit thread about traditional cooking techniques. The most insightful comment — bar none — is buried at the bottom. You almost miss it.

It's written in Portuguese.

The person clearly knows what they're talking about. They're detailed, nuanced, passionate. But only 3% of Reddit users will ever read it. The other 97% scrolled past without even knowing what they missed.

That comment deserved 10,000 upvotes. It got 2.

This happens billions of times a day across every social platform on the internet.

Here's the uncomfortable truth: only 25.9% of internet users speak English as their primary language. Yet English dominates over 60% of online content. The global conversation we think we're having? It's actually a very exclusive English-speaking club.

I couldn't stop thinking about this. So I built EchoBoard — a social discussion platform where language is no longer a barrier to being heard.

Write in Hindi. Someone in Tokyo reads it in Japanese. A student in Paris sees it in French. A developer in São Paulo reads it in Portuguese.

Real-time. Zero friction. No Google Translate copy-paste.

Here's exactly how I built it — and what you can steal for your own projects.

💡 What You'll Build By Reading This

By the end of this post, you'll understand:

How to build a 3-API fallback translation chain that never fails
How to detect a user's language from their post content automatically
How to build real-time, language-aware feeds using React + Supabase
How to layer i18next UI localization on top of dynamic content translation
The architectural decisions I made (and the ones I regret)

🛠️ The Tech Stack

Frontend:    React 19 + Vite 7
Styling:     Tailwind CSS 4
Auth:        Clerk (Google + GitHub sign-in)
Database:    Supabase (PostgreSQL + Realtime)
Translation: MyMemory → LibreTranslate → Lingva (fallback chain)
i18n:        i18next + react-i18next
Icons:       Lucide React
Routing:     React Router v7
Deploy:      Vercel (free tier)

The most critical architectural decision was the translation system. Let me explain why I chose three APIs instead of one — and why that turned out to be the best call I made.

🌍 The Translation Engine: Why a 3-API Fallback Chain?

When I started, I naively assumed one translation API would be enough. I was wrong.

Here's the reality of free/low-cost translation APIs:

API	Free Tier	Reliability	Coverage
MyMemory	5000 chars/day	High	70+ languages
LibreTranslate	Self-hostable	Medium	30+ languages
Lingva	Unlimited (Google proxy)	Medium	100+ languages

None of them are perfect alone. But chained together? Rock solid.

Here's the hook I built — useTranslationEngine.js:

// src/hooks/useTranslationEngine.js
import { useState, useCallback } from 'react';

const APIS = [
  {
    name: 'MyMemory',
    translate: async (text, sourceLang, targetLang) => {
      const url = `https://api.mymemory.translated.net/get?q=${encodeURIComponent(text)}&langpair=${sourceLang}|${targetLang}`;
      const res = await fetch(url);
      const data = await res.json();

      if (data.responseStatus !== 200) throw new Error('MyMemory failed');
      return data.responseData.translatedText;
    }
  },
  {
    name: 'LibreTranslate',
    translate: async (text, sourceLang, targetLang) => {
      const res = await fetch('https://libretranslate.com/translate', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          q: text,
          source: sourceLang,
          target: targetLang,
          format: 'text'
        })
      });
      const data = await res.json();
      if (data.error) throw new Error('LibreTranslate failed');
      return data.translatedText;
    }
  },
  {
    name: 'Lingva',
    translate: async (text, sourceLang, targetLang) => {
      const url = `https://lingva.ml/api/v1/${sourceLang}/${targetLang}/${encodeURIComponent(text)}`;
      const res = await fetch(url);
      const data = await res.json();
      if (!data.translation) throw new Error('Lingva failed');
      return data.translation;
    }
  }
];

export function useTranslationEngine() {
  const [isTranslating, setIsTranslating] = useState(false);
  const [translationSource, setTranslationSource] = useState(null);

  const translate = useCallback(async (text, sourceLang, targetLang) => {
    // No translation needed if same language
    if (sourceLang === targetLang || !text?.trim()) return text;

    setIsTranslating(true);

    for (const api of APIS) {
      try {
        console.log(`[Translation] Trying ${api.name}...`);
        const result = await api.translate(text, sourceLang, targetLang);
        setTranslationSource(api.name);
        setIsTranslating(false);
        return result;
      } catch (err) {
        console.warn(`[Translation] ${api.name} failed, trying next...`, err.message);
      }
    }

    // All APIs failed — return original text with a flag
    setIsTranslating(false);
    return text;
  }, []);

  return { translate, isTranslating, translationSource };
}

The magic is in the for loop. If MyMemory hits its daily limit, we silently fall through to LibreTranslate. If LibreTranslate is down, we hit Lingva. The user never sees an error. They just see translated content.

💡 Pro Tip: Log translationSource to your analytics. If you see Lingva firing too often, you might be hitting MyMemory's daily limit — a sign you need to upgrade or add a fourth API.

🗄️ The Database Schema That Makes It Work

The hardest architectural decision: where do you store translations?

I chose to store the original post and generate translations on-the-fly at read time, rather than pre-translating into every language. Here's why:

Storage efficiency — You don't know which languages your users will need
Accuracy — You always translate from the original, not from a previous translation
Flexibility — Add a new UI language? No re-migration needed

Here's the core schema I ran in Supabase:

-- Posts table — stores original content only
CREATE TABLE posts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title_original TEXT,
  body_original TEXT,
  author_id TEXT REFERENCES profiles(id),
  community_id UUID REFERENCES communities(id),
  locale TEXT DEFAULT 'en',       -- The language the post was written in
  upvotes INTEGER DEFAULT 0,
  comment_count INTEGER DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Comments table — same pattern
CREATE TABLE comments (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  post_id UUID REFERENCES posts(id),
  author_id TEXT REFERENCES profiles(id),
  body_original TEXT,
  locale TEXT DEFAULT 'en',      -- The language the comment was written in
  created_at TIMESTAMPTZ DEFAULT NOW()
);

The locale column on each post is the key. When user A posts in Hindi (hi) and user B is viewing in Japanese (ja), the feed component knows to call translate(post.body_original, 'hi', 'ja').

⚡ The Feed Component: Real-Time + Multilingual

Here's a simplified version of the feed post card that handles translation, language detection, and the "See Original" toggle:

// src/components/PostCard.jsx
import { useState, useEffect } from 'react';
import { useTranslation } from 'react-i18next';
import { useTranslationEngine } from '../hooks/useTranslationEngine';

export function PostCard({ post }) {
  const { i18n } = useTranslation();
  const { translate, isTranslating } = useTranslationEngine();

  const [displayTitle, setDisplayTitle] = useState(post.title_original);
  const [displayBody, setDisplayBody] = useState(post.body_original);
  const [showOriginal, setShowOriginal] = useState(false);
  const [isTranslated, setIsTranslated] = useState(false);

  const userLocale = i18n.language;       // e.g., 'ja'
  const postLocale = post.locale || 'en'; // e.g., 'hi'

  useEffect(() => {
    const needsTranslation = userLocale !== postLocale;

    if (!needsTranslation || showOriginal) {
      setDisplayTitle(post.title_original);
      setDisplayBody(post.body_original);
      setIsTranslated(false);
      return;
    }

    async function fetchTranslation() {
      const [translatedTitle, translatedBody] = await Promise.all([
        translate(post.title_original, postLocale, userLocale),
        translate(post.body_original, postLocale, userLocale),
      ]);

      setDisplayTitle(translatedTitle);
      setDisplayBody(translatedBody);
      setIsTranslated(true);
    }

    fetchTranslation();
  }, [userLocale, showOriginal, post]);

  return (
    <div className="bg-white dark:bg-gray-900 rounded-xl p-6 border border-gray-200 dark:border-gray-800">
      {isTranslating && (
        <div className="flex items-center gap-2 text-sm text-blue-500 mb-3">
          <div className="w-3 h-3 border-2 border-blue-500 border-t-transparent rounded-full animate-spin" />
          Translating...
        </div>
      )}

      <h2 className="text-xl font-bold text-gray-900 dark:text-white mb-2">
        {displayTitle}
      </h2>

      <p className="text-gray-600 dark:text-gray-300 leading-relaxed">
        {displayBody}
      </p>

      {isTranslated && (
        <button
          onClick={() => setShowOriginal(prev => !prev)}
          className="mt-3 text-sm text-blue-500 hover:underline flex items-center gap-1"
        >
          🌐 {showOriginal ? 'See Translation' : `See Original (${postLocale.toUpperCase()})`}
        </button>
      )}
    </div>
  );
}

Notice Promise.all for translating title and body simultaneously. This cuts translation wait time roughly in half compared to doing them sequentially.

💡 Pro Tip: Memoize your translation results in a useRef or sessionStorage keyed by ${postId}-${sourceLang}-${targetLang}. On a busy feed, the same post could get translated multiple times as users scroll up and down — caching eliminates redundant API calls.

🌐 Two-Layer i18n: UI vs. Content

This is where most people get confused. EchoBoard has two completely separate translation systems:

Layer	What it translates	How
UI Layer	Buttons, menus, labels, navigation	i18next + JSON locale files
Content Layer	Posts, comments, bios	Translation API chain at runtime

The UI layer uses standard i18next. Here's the setup:

// src/i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import LanguageDetector from 'i18next-browser-languagedetector';

// Import all 9 language files
import en from './locales/en.json';
import es from './locales/es.json';
import fr from './locales/fr.json';
import de from './locales/de.json';
import ja from './locales/ja.json';
import ko from './locales/ko.json';
import zh from './locales/zh.json';
import it from './locales/it.json';
import hi from './locales/hi.json';

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources: { en, es, fr, de, ja, ko, zh, it, hi },
    fallbackLng: 'en',
    interpolation: { escapeValue: false },
    detection: {
      order: ['localStorage', 'navigator'],
      caches: ['localStorage'],
    },
  });

export default i18n;

When a user switches from English to Japanese, i18n.changeLanguage('ja') fires two cascading effects:

All UI strings (nav, buttons, labels) immediately render in Japanese via i18next
All feed posts re-trigger their useEffect and fetch new translations from the API chain

The result feels instant because the UI switches immediately, while content translation loads progressively.

🔥 The Trending System

Trending isn't just "most upvotes." Time-decay matters. A post from a week ago with 500 upvotes shouldn't outrank a post from this morning with 50.

Here's the Supabase query with a simple time-weight:

// src/lib/trending.js
export async function fetchTrendingPosts(filter = 'week', supabase) {
  const timeFilters = {
    today: new Date(Date.now() - 24 * 60 * 60 * 1000).toISOString(),
    week:  new Date(Date.now() - 7  * 24 * 60 * 60 * 1000).toISOString(),
    all:   null,
  };

  let query = supabase
    .from('posts')
    .select('*, profiles(username, avatar_url), communities(name)')
    .order('upvotes', { ascending: false })
    .limit(25);

  const since = timeFilters[filter];
  if (since) {
    query = query.gte('created_at', since);
  }

  const { data, error } = await query;
  if (error) throw error;
  return data;
}

The filter tabs (Today / This Week / All Time) just change the filter parameter. Clean, simple, effective.

🏘️ Communities with Real-Time Subscriptions

Supabase Realtime is genuinely one of the most underrated features in the modern stack. When someone posts in a community you've joined, you get a notification — in real time — with zero polling.

// src/hooks/useCommunityRealtime.js
import { useEffect } from 'react';
import { supabase } from '../lib/supabase';

export function useCommunityRealtime(communityId, onNewPost) {
  useEffect(() => {
    if (!communityId) return;

    const channel = supabase
      .channel(`community:${communityId}`)
      .on(
        'postgres_changes',
        {
          event: 'INSERT',
          schema: 'public',
          table: 'posts',
          filter: `community_id=eq.${communityId}`
        },
        (payload) => {
          console.log('[Realtime] New post in community:', payload.new);
          onNewPost(payload.new);
        }
      )
      .subscribe();

    return () => {
      supabase.removeChannel(channel);
    };
  }, [communityId, onNewPost]);
}

When this fires, we add a "New posts available — click to refresh" banner at the top of the feed, just like Reddit. No jarring full-page refreshes.

🔔 The Notification System

Notifications track three events: upvotes, comments, and new community posts. Here's the schema:

CREATE TABLE notifications (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id TEXT NOT NULL,
  type TEXT NOT NULL,          -- 'upvote' | 'comment' | 'community_post'
  post_id UUID REFERENCES posts(id),
  actor_id TEXT,               -- who triggered it
  read BOOLEAN DEFAULT FALSE,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

A Supabase database trigger inserts a notification row whenever a vote is added or a comment is created. The frontend subscribes to notifications table changes filtered by user_id, updating the badge count in real time.

// Simplified notification subscription
const channel = supabase
  .channel('my-notifications')
  .on(
    'postgres_changes',
    {
      event: 'INSERT',
      schema: 'public',
      table: 'notifications',
      filter: `user_id=eq.${currentUserId}`
    },
    (payload) => {
      setUnreadCount(prev => prev + 1);
      setNotifications(prev => [payload.new, ...prev]);
    }
  )
  .subscribe();

💡 Lessons Learned (The Hard Way)

1. Translate on read, not on write

I briefly considered pre-translating every post into all 9 languages on creation. At 9 languages × 3 API calls = 27 API calls per post. I backed out of that immediately. On-demand translation at read time is the right call.

2. Always store the original locale with the content

If you don't store locale: 'hi' on the post, you have no idea what language to translate from. You'd have to detect it on every read — expensive and often inaccurate for short text.

3. Rate limit translation calls aggressively

During testing I accidentally translated the same posts 400 times in an afternoon. Add a useRef cache. Seriously.

4. Dark mode first, light mode second

Building dark mode as an afterthought is painful. I committed to dark mode as the default from day one and added light mode as an opt-in toggle. Every CSS decision was cleaner because of this.

5. Mobile-first navigation changed everything

The desktop sidebar nav I designed first was beautiful. It was also completely unusable on mobile. The bottom tab bar I ended up building for mobile was so much cleaner that I actually prefer it to the desktop version now.

📁 Project Structure

Echo-Board/
├── src/
│   ├── hooks/
│   │   └── useTranslationEngine.js   ← The 3-API fallback chain
│   ├── lib/
│   │   └── supabase.js
│   ├── locales/                      ← 9 language JSON files
│   │   ├── en.json
│   │   ├── ja.json
│   │   └── ...
│   ├── App.jsx
│   ├── FeedPage.jsx                  ← Main multilingual feed
│   ├── TrendingPage.jsx
│   ├── CommunitiesPage.jsx
│   ├── NotificationsPage.jsx
│   ├── SavedPostsPage.jsx
│   └── i18n.js                      ← i18next config
├── vercel.json                       ← SPA routing fix
└── package.json

🚀 Deploy to Vercel in 5 Minutes

1. Environment Variables

VITE_SUPABASE_URL=your_supabase_project_url
VITE_SUPABASE_ANON_KEY=your_supabase_anon_key
VITE_CLERK_PUBLISHABLE_KEY=your_clerk_publishable_key

2. Fix SPA Routing

Create vercel.json at the root — without this, any route other than / returns 404 on refresh:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

3. After Deploying

Add your Vercel domain (e.g., echo-board.vercel.app) to:

Clerk Dashboard → Allowed Origins
Supabase Dashboard → Auth → URL Configuration → Redirect URLs

That's it. Total deploy time: under 5 minutes.

📊 What This Unlocks (The Product Case)

Here's the thing nobody talks about when they build multilingual features: it's not just a UX improvement. It's a fundamental market expansion.

Metric	English-only	Multilingual
Addressable Users	25.9% of internet	99%+ of internet
Average Session Duration	Baseline	2-3x longer (users feel at home)
Community Contribution Rate	Baseline	Significantly higher (people post in their native tongue)
Return Visits	Baseline	Higher (content feels personal)

A farmer in rural Maharashtra has ideas about sustainable agriculture that agricultural researchers in Amsterdam would genuinely benefit from. A poet in Kyoto has something to say that a student in Buenos Aires would feel deeply. They're just not saying it in English.

EchoBoard gives them a mic. And makes sure everyone can hear it.

🎯 What's Next

Here's what's on the roadmap:

Language detection on compose — detect what language you're writing in as you type and show a small flag indicator, so you know EchoBoard understood you
Translation quality feedback — a simple thumbs up/down on each translation that feeds back into API selection logic
Cached translations in Supabase — store popular post translations so the same content isn't re-translated on every view
Audio translation — post a voice note in Hindi, listeners hear it in their language

🔗 Links

GitHub: Echo-Board on GitHub
Live Demo: echo-board.vercel.app

🏁 Final Thoughts

The internet was supposed to connect everyone. But somewhere along the way, it became a mostly English-speaking club with a few translation buttons bolted on as an afterthought.

The next great idea might come from someone who has never written a tweet in English. The next breakthrough conversation in your industry might happen in Mandarin, or Arabic, or Swahili — and you'd never know, because it was never translated.

EchoBoard is a small bet that borderless conversation is possible. And based on what I've seen while building it, I think it's a bet worth making.

If you're building something multilingual, or you want to steal anything from this codebase — please do. That's what it's here for.

Drop a comment below if you have questions about the translation architecture, the Supabase setup, or anything else. I'll answer every one.

Built with React 19, Supabase, Clerk, Tailwind CSS 4, and a genuine belief that every voice deserves to be heard.

Tags: #react #javascript #webdev #tutorial #opensource #i18n #supabase #buildinpublic

I Built a Global Store That Automatically Adjusts Price and Language (No JSON Files Required)

Arjun — Sat, 07 Feb 2026 06:54:30 +0000

Let's be honest. Internationalization is usually painful. 🌍

If you have ever built a global app, you know the struggle. You create a locales folder. You create en.json. Then es.json. Then fr.json. You spend hours copying keys and translating simple words.

And if you change one sentence? You have to update five different files.

For my latest hackathon project, Prism, I wanted to stop doing that. I wanted to build a storefront that didn't just translate words but actually adapted to the user.

Here is how I used Next.js 15 and AI to build a store that changes prices and languages based on who is visiting. The best part? I didn't maintain a single translation file.

🚨 The Problem
Most "Link-in-Bio" stores treat every visitor the same. They show the price in USD and the text in English.

But if a user visits from India, a $50 ebook is expensive. And if they visit from Brazil, they probably want to read in Portuguese.

I built Prism to solve this 🚀:

Detect Location: Know where the user is visiting from.

Adjust Price: Apply Purchasing Power Parity (PPP). For example, $50 becomes ₹4000 automatically.

Translate Content: Use AI to rewrite the description in the local language instantly.

🛠️ The Tech Stack
I kept it modern and fast:

Framework: Next.js 15 (App Router)

Database: Supabase (for Auth and Data)

The Magic: Lingo.dev (for AI Localization)

⚡Ditching the JSON Files
In a normal app, your product page code usually looks like this:

TypeScript

{t('product_title')}

{t('product_desc')}

Then you have to go write those translations manually in a separate file. It is boring work. 😴

With Prism, I used the Lingo.dev SDK. Instead of static keys, the AI generates context-aware translations on the fly.

It understands that "System" in Spanish should be "Sistema" in the context of computers, not biology. This saved me hours of manual work.

📸The Result
Here is what happens when you actually visit the store.

The US Visitor:

Language: English

Price: $49.00

Vibe: Standard.

The Indian Visitor:

Language: Hindi (Auto-translated)

Price: ₹4000 (PPP Adjusted)

Vibe: Localized.

🚀 Why This Matters
We often ignore the "International" part of the World Wide Web. We build for our own timezone and currency.

By automating the hard stuff like translation and currency conversion, we aren't just writing better code. We are opening our apps to the 85% of the world that doesn't speak English as a first language.

I am submitting this for the Lingo.dev hackathon. If you want to check out the code or star the repo, here is the link:

🔗 [https://github.com/CoderOtakuX/Prism]

Happy coding! 💻