# Palash Debnath — palash.dev > Software engineer and product builder in India. Building open-source, local-first tools for AI audio, media, and developer memory. --- ## Canonical links - Website: https://palash.dev/ - GitHub: https://github.com/debpalash - X: https://x.com/idebpalash - Contact: mailto:hi@palash.dev - RSS: https://palash.dev/rss.xml - Humans.txt: https://palash.dev/humans.txt ## Projects ### VoiceStudio.sh - **Status**: live - **Tagline**: Cinematic audio dubbing, cloning & voice generation - **Description**: A cinematic audio dubbing, cloning and voice generation studio. Enterprise-grade processing with AI-powered voice synthesis, 600+ language support, and self-hosted deployment. - **Page**: https://palash.dev/omnivoice/ - **Source**: https://github.com/debpalash/VoiceStudio - **Stack**: Python, Tauri, CUDA, Docker, MLX, Whisper - **Keywords**: VoiceStudio.sh, VoiceStudio, OmniVoice, AI voice cloning, AI dubbing software, voice generation studio, self-hosted ElevenLabs alternative, Palash Debnath ### memxt - **Status**: live - **Tagline**: Local-first long-term memory for AI coding agents - **Description**: The fastest benchmarked open-source AI memory system — a single static binary that gives coding agents persistent, on-device memory across sessions. No cloud, no Python, nothing leaves your machine. - **Page**: https://palash.dev/memxt/ - **Website**: https://yupcha.github.io/memXT/ - **Source**: https://github.com/Yupcha/memXT - **Stack**: Zig, LLM, MCP, AI Memory - **Keywords**: memxt, memxt agent memory, AI agent memory, long-term memory for AI agents, MCP memory server, local-first AI memory, Palash Debnath ### Opal - **Status**: live - **Tagline**: Play everything — the evolved media player - **Description**: One media player for everything — files, sites, servers, and feeds. Say a title, a file, a magnet, or a vibe, and Opal finds and plays it a moment later. AI-powered discovery built for speed in Zig, running on macOS, Linux, and Windows. - **Page**: https://palash.dev/opal/ - **Website**: https://opal.palash.dev - **Source**: https://github.com/debpalash/Opal - **Stack**: Zig, AI, Desktop - **Keywords**: Opal, Opal media player, AI media player, play everything media player, universal media player, Zig media player, Palash Debnath --- ## Experiments ### omnivoice-gallery - **Description**: Voice sample gallery companion for OmniVoice Studio. - **Language**: Python - **URL**: https://github.com/debpalash/omnivoice-gallery ### opal-plugins - **Description**: Source endpoints powering Opal's plugin system. - **Language**: JSON - **URL**: https://github.com/debpalash/opal-plugins ### sshbox - **Description**: Sandboxed SSH environments, written in Go. - **Language**: Go - **URL**: https://github.com/debpalash/sshbox ### zig-bypassdpi - **Description**: Cross-platform userspace DPI-bypass proxy in pure Zig — SNI ClientHello fragmentation, no driver or root. - **Language**: Zig - **URL**: https://github.com/debpalash/zig-bypassdpi --- ## Blog Posts ### Opal: Play Everything - **Date**: 2026-07-08 - **Description**: It's 11 PM and you just want to watch something. So why are there nine tabs open? Opal is my answer — one media player for the next decades of entertainment. - **Tags**: opal, zig, media, programs - **URL**: https://palash.dev/blog/opal-play-everything/ #### Content ## Opal: Play Everything It's 11 PM and you just want to watch something. So why are there nine tabs open? A player for the files. A site for the show. An app for the server. A wiki for "what episode was that." A feed deciding what you see next. For decades the media player has been the dumb end of the pipeline. Double-click, decode, render. All the intelligence — what to watch, where it is, what it's even called — got outsourced to browsers, apps, and other people's algorithms. Opal's whole thesis is that this is *one job*. You say what you're in the mood for — a title, a file, a magnet, a vibe — and a moment later you're watching it. That's it. That's the app. ## What that looks like Open Opal late and it knows it's late. Time-aware greeting, an ask-anything box, tonight's trending row. - Type a title — it finds it. - Drop a file — it plays. - Paste a magnet — it streams. - Describe a vibe — the AI takes it from there. Search, browse, chat, player. One window. No tabs. ## Under the hood Zig. Because a media player should start faster than your TV. No runtime, no Electron, no half-gigabyte of RAM to show you a play button. Runs on macOS, Linux, and Windows. Sources live in a plugin system, so the app stays clean and the endpoints stay swappable. ## Get it GPL-3.0 on [GitHub](https://github.com/debpalash/Opal), `brew tap debpalash/tap` if you're on a Mac. The next decades of entertainment shouldn't belong to a feed. They should belong to whoever's holding the remote. ### memxt: Your Agent Forgets. Mine Doesn't. - **Date**: 2026-07-08 - **Description**: Local-first long-term memory for AI coding agents — one static binary, sub-millisecond semantic recall, nothing leaves your machine. - **Tags**: memxt, zig, ai, agents - **URL**: https://palash.dev/blog/memxt-agent-memory/ #### Content ## memxt: Your Agent Forgets. Mine Doesn't. Most AI coding sessions start amnesiac. You re-explain the architecture. You re-state why you chose SQLite over Postgres. The agent cheerfully contradicts a decision it helped make last week. Context window ends, knowledge dies. Every session is groundhog day. memxt is my fix: persistent, on-device memory your agent can search and write. Wired into Claude Code through MCP tools and session hooks — the agent wakes up already knowing your codebase and your decisions. ## The numbers - **One static binary.** ~6 MB, plus a 45 MB embedding model. No Python, no Docker, no vector database to babysit. - **Session wake-up in ~10 ms.** - **Sub-millisecond vector search** once the model is resident. - **100% local.** Embeddings, storage, and search run on-device — llama.cpp + sqlite-vec. No API keys. No network at query time. The fastest benchmarked open-source AI memory system. The benchmarks are [in the repo](https://github.com/debpalash/memxt) — run them yourself. ## Why local, why Zig Two rules I refuse to break. **Memory infrastructure should be invisible.** If recall adds seconds to your loop, you'll turn it off. 10 ms wake-up means it's just *there*, every session, and you stop thinking about it. That's what Zig buys — and it's why memxt started life as a 200× faster port of an existing memory tool. **Your decisions are your codebase.** The reasoning behind your architecture is some of the most sensitive data you produce. It should not live in someone else's cloud so your agent can remember it. Nothing leaves your machine. That's the whole design. ## Install ```bash curl -fsSL https://raw.githubusercontent.com/Yupcha/memxt/main/install.sh | bash ``` Detects your platform, drops the binary and model in `~/.memxt/`, done. Your agent already works hard. Let it remember. ### Why I Built an Open-Source ElevenLabs - **Date**: 2026-07-08 - **Description**: OmniVoice Studio — voice cloning, design, dubbing and dictation as a local desktop app. 600+ languages, self-hosted, yours. - **Tags**: omnivoice, ai, audio, open-source - **URL**: https://palash.dev/blog/omnivoice-open-source-elevenlabs/ #### Content ## Why I Built an Open-Source ElevenLabs Voice AI got good. Then it got rented. The best cloning and dubbing live behind APIs: your voice goes to someone's cloud, comes back priced per second, under terms that can change any quarter. For a demo, fine. For a studio you depend on — or a voice that happens to be *yours* — no. So I built OmniVoice Studio: the open-source ElevenLabs alternative, as a desktop app. Clone, design, create, dub, dictate. Locally. ## What's inside - **Cloning and voice design** — capture a voice or build one from scratch. - **Dubbing pipeline** — cinematic, multi-track, end to end. - **Dictation** — your machine, your microphone, your text. - **600+ languages.** - **Swappable engines** — Whisper and friends, on your hardware: MLX on Apple silicon, CUDA on NVIDIA, Docker when you want it on a server. - **An OpenAPI surface** — the studio doubles as a self-hosted API, so your tools can speak too. Tauri desktop app around a Python core. Launchpad, studio, library, gallery — it's built to be lived in, not demoed. ## The bet Voice is identity. It's the most personal biometric you casually give away, and the current market structure is "upload it and subscribe to yourself." I bet people would rather own the stack. Just shy of 8,000 GitHub stars later, I'd say the bet is holding. Enterprise-grade processing with nothing leaving your machine — that's not a feature tier. That's the point. ## Get it [github.com/debpalash/OmniVoice-Studio](https://github.com/debpalash/OmniVoice-Studio) — free, open source, self-hosted. Your voice. Your hardware. Your studio. ### Building a Tech Company from Agartala - **Date**: 2026-07-07 - **Description**: Two years of hiring posts, one bootcamp with no syllabus, and why I'm building AI products from a city that isn't on the startup map. - **Tags**: startup, agartala, hiring, india - **URL**: https://palash.dev/blog/building-from-agartala/ #### Content ## Building a Tech Company from Agartala Open the startup map of India. Bangalore. Gurgaon. Hyderabad. Pune. Now keep going north-east until the map runs out of logos. That's home. Agartala, Tripura. That's where we build Yupcha. People ask why. The honest answer: someone had to be first. ## The problem nobody warns you about When I posted our first hiring call, I expected silence. I got 200 comments. That's the twist about building here. The demand for opportunity is enormous. What's thin is *experience* — there's no pool of seniors to poach, no ex-FAANG folks between jobs, no meetup where your next staff engineer is giving a talk. Hundreds of applicants. Very few who have shipped anything to production. Most founders solve this by not being here. Remote team, Bangalore address, done. We decided to solve it the hard way. ## Attitude over CV Early on I wrote a line in one of our job posts that became the whole philosophy: > It doesn't matter what's on your CV, rather what's on your attitude. We hired for curiosity and grit, then built the experience ourselves. Python, Go, C++, JavaScript, ML — role after role, batch after batch. Day shifts in office, evening shifts remote, hybrid for the roles that could handle it. Whatever structure made it possible for someone in Agartala to do serious engineering work, we tried it. Some bets failed. Plenty of people used us as a launchpad and left — that's fine, that's what launchpads are for. But some stayed, and the ones who stayed became the kind of engineers you cannot hire anywhere: people who've touched every layer of the stack because there was nobody else to hand it to. ## The bootcamp with no syllabus When you can't hire experience, you grow it. So we ran the Yupcha Bootcamp: three months, twelve seats, no traditional syllabus. Learning-by-building only. Real projects, just-in-time learning, personalized material as you go. Python and ML application design, backend and production design, data scraping, microservices, reactive frontends — whatever the project demanded, that's what you learned that week. The pitch was simple: learn directly from people shipping industry-level projects, then maybe get hired by them. Several did. That post did 4,000+ impressions — more than any product launch we've done. Which tells you something: the appetite to *build* is here. It was always here. It just needed a door. ## What it costs, what it buys Building from Agartala costs repetition. Two years of hiring posts. Explaining to every candidate's family what a SaaS company is. Being the only reference point for what a tech career looks like in the neighborhood. What it buys: a team with real loyalty. A cost structure that lets us be patient. And a kind of meaning that's hard to get in a saturated market — every hire here changes a life trajectory, visibly, immediately. Today that team ships an AI interviewer doing real-time video interviews in Indian languages, an agentic HR platform, resume tools, open-source projects. From Tripura. Not despite the location. From it. The map runs out of logos up here. Give it a few years. ### Some Will Call AGI a TechnoGod - **Date**: 2026-07-06 - **Description**: Why every nation needs sovereign AI, what wars will actually be fought with, and why we ship Sarvam's indic models in production at Yupcha. - **Tags**: ai, india, sovereign-ai, opinion - **URL**: https://palash.dev/blog/sovereign-ai/ #### Content ## Some Will Call AGI a TechnoGod Some will call AGI a TechnoGod. I think that's roughly the right frame — not because it'll be divine, but because of how nations will behave around it. By the time AGI-class systems arrive, every country will need its own. Not for prestige. For sovereignty. ## The uncomfortable thought experiment Newer ways of war will be fought with AI. Not tanks — models, data, and the infrastructure underneath them. And here's the part people skip: what AI consumes most is power and water. Compute has a geography. Whoever controls that geography controls the intelligence built on it. Now run the thought experiment. Suppose one nation gets AGI first — say the US. What does its leadership actually do with a decisive intelligence advantage? You already know. Every other country gets hacked, every secret gets stored, and the leverage gets used exactly when it's needed. Or don't they always find a way? That's not a conspiracy theory. That's just what a decisive advantage *is*. The question for everyone else isn't "will they" — it's "what's our position when they do." ## India's position India is a few years late to the frontier. That's the honest assessment. But late isn't lost. Sarvam, Gnani, and a handful of other labs are doing genuine frontier work on indic-language models — and the gap closes faster when the models have actual production users instead of just benchmark charts. A sovereign AI stack isn't built by government announcements. It's built by a supply chain of customers. Labs need revenue, feedback loops, and deployments that stress the models in real conditions. That part is on us — the builders. ## Our receipts At Yupcha, we ship Sarvam's TTS and language models in production, inside our AI video interviewer. Hiring in India doesn't happen in English alone. A candidate interviewing in their own language performs like themselves; the same candidate forced through a foreign language performs like a translation. Indic TTS and LLMs make first-round interviews work across Indian languages — and no frontier lab in San Francisco is going to prioritize Tripura's languages before an Indian lab does. So the choice was easy. We support our leading AI labs by being their customer, in production, with real traffic. ## The ask You don't need to build a foundation model to contribute to sovereign AI. You need to route real workloads to local labs. In your industry, whatever it is — pick the domestic model where it's viable, file the bugs, pay the invoices. That's what "catching up" actually looks like at the system level: a thousand companies choosing to be the feedback loop. Every country should have its own AI by the time it matters. Ours gets built the same way everything real gets built — by people shipping with it. ### We Built an AI Interviewer. It's Not Here to Replace HR. - **Date**: 2026-07-05 - **Description**: First-round interviews are a grind of repeated questions and manual notes. Here's what we built at Yupcha instead — and what building it taught us. - **Tags**: ai, product, yupcha, hiring - **URL**: https://palash.dev/blog/ai-interviewer/ #### Content ## We Built an AI Interviewer. It's Not Here to Replace HR. "Recruiters just post jobs." That's one of the biggest misconceptions about hiring. Behind every successful hire are hundreds of resumes, interview scheduling, candidate follow-ups, hiring manager coordination, offer negotiations — and sometimes starting all over again. And the worst grind of all: first-round interviews. The same questions, asked the same way, to dozens of candidates, evaluated by hand, week after week. Recruiters don't need more work. They need less *repetitive* work. That's exactly why we built the Yupcha AI Interviewer. ## What it actually does Not magic. Structure. - **Structured interview templates** — build them yourself or let AI generate them from the role. Every candidate gets the same fair, deliberate interview. - **AI-conducted first rounds, in real time** — video interviews that run themselves, at whatever hour suits the candidate. Finish dozens of interviews before your day starts. - **One place for the pipeline** — candidates, statuses, and follow-ups without the spreadsheet archaeology. - **Structured assessment reports** — not a raw transcript to wade through. Clear, comparable evaluations against the template you defined. The human makes the hiring decision. The machine compresses everything before the decision. ## The part I care most about: language Hiring in India doesn't happen in English alone — but interviews mostly do, and that quietly filters for English fluency instead of actual ability. So we wired indic language support deep into the interviewer, built on Sarvam's TTS and language models. A candidate interviewing in their own language performs like themselves. That's not a feature checkbox; for hiring across India, it's the whole point. (It's also our small bet on sovereign AI — routing real production traffic to Indian labs. I wrote more about that separately.) ## What building it taught us **Structure beats vibes.** The template is the product. An AI interviewer without structured templates is just a chatbot with opinions; with them, every candidate gets measured against the same bar, and the reports become comparable. **Reports beat transcripts.** Nobody reads forty transcripts. Everyone reads forty one-page assessments. Most of our iteration went into what comes *out* of the interview, not what happens in it. **Trust is earned in the failure cases.** What happens when the candidate's connection drops, when they misunderstand a question, when the model mishears? Boring reliability work — and it's where an HR tool lives or dies. **Replacing people is the wrong product.** Every time we framed a feature as "so HR doesn't have to be there," it got worse. Every time we framed it as "so HR walks into the final round already informed," it got better. Support, not substitution. The funnel gets compressed; the judgment stays human. ## Where it stands The AI Interviewer is live at [yupcha.com](https://yupcha.com), running structured first-round interviews for teams that would rather spend their hours on final rounds and offers than on repetition. Hiring doesn't have to be slow, repetitive, or exhausting. It just has to be structured — and honest about which parts deserve a human. ### Hello World — Welcome to My Corner of the Internet - **Date**: 2026-04-26 - **Description**: First post on the new blog. A brief intro about who I am, what I build, and what to expect from this space. - **Tags**: personal, meta, introductions - **URL**: https://palash.dev/blog/hello-world/ #### Content ## Hello, World 👋 Welcome to **palash.dev** — my personal corner of the internet where I write about building products, engineering craft, and the occasionally unhinged side of shipping software. ## What to expect This blog will cover a few recurring themes: - **Product engineering** — building things that ship, not just compile - **Architecture deep-dives** — decisions that survive production - **Developer tooling** — the stuff that makes the craft enjoyable - **Shipping fast** — velocity without sacrificing quality ## The stack behind this site This site is built with: ``` Astro 6 → Static-first, content-focused framework React → Interactive islands where needed Tailwind v4 → Utility-first CSS with @theme config Cloudflare → Edge deployment, zero cold starts MDX → Markdown + components for rich content ``` ## Why Astro? I've built sites with Next.js, Gatsby, Hugo, and raw HTML. Astro hits a sweet spot for content-focused sites: - **Zero JS by default** — ship HTML, hydrate only what needs interactivity - **Content collections** — type-safe frontmatter, no more YAML guessing - **View transitions** — smooth page navigation without an SPA runtime - **Island architecture** — React where you need it, Astro everywhere else More posts coming soon. If you're reading this, thanks for stopping by. *— Palash* ### On Shipping Fast Without Cutting Corners - **Date**: 2026-04-20 - **Description**: Speed isn't the opposite of quality. Here's how I think about velocity, iteration, and knowing when good enough is good enough. - **Tags**: engineering, velocity, product - **URL**: https://palash.dev/blog/on-shipping-fast/ #### Content ## On Shipping Fast Without Cutting Corners There's a persistent myth in software: you can have it fast, or you can have it right. Pick one. I disagree. The best engineers I've worked with are both fast *and* precise. The trick isn't choosing between speed and quality — it's understanding which quality dimensions matter *right now*. ## The Velocity Framework I think about shipping speed across three axes: ### 1. Decision Speed The fastest code is the code you don't deliberate on forever. Most technical decisions are reversible. The ones that aren't — data models, auth architecture, public APIs — deserve deliberation. Everything else? Make a call and move. ### 2. Iteration Cycles Short feedback loops compound. If your build takes 30 seconds, you iterate differently than if it takes 5 minutes. Invest in: - **Hot reload** that actually works - **Type safety** that catches errors before runtime - **Tests** that run in under a second - **Preview deployments** for every PR ### 3. Scope Discipline The hardest skill in product engineering isn't coding — it's scoping. A feature that ships in 2 days and solves 80% of the problem beats a feature that ships in 2 weeks and solves 95%. ```typescript // The 80% solution that ships today function formatDate(date: Date): string { return date.toLocaleDateString('en-US', { year: 'numeric', month: 'long', day: 'numeric', }); } // vs. The 95% solution that ships... eventually // Supports 47 locales, 12 calendar systems, // relative time, time zones, and a partridge // in a pear tree ``` ## When to slow down Not everything should be fast. Slow down for: - **Security decisions** — auth, encryption, access control - **Data migrations** — there's no "undo" for production data - **API contracts** — your consumers will build on your mistakes - **Hiring** — a wrong hire costs more than a delayed hire ## The meta-skill The real skill isn't being fast. It's knowing your speed. Understanding what you can ship in a day, a week, a sprint — and being honest about it. Ship more. Ship faster. But ship *intentionally*. ### Building with AI — Lessons from the Trenches - **Date**: 2026-04-15 - **Description**: Practical lessons from integrating AI into real products. Not the hype — the craft. - **Tags**: ai, engineering, product - **URL**: https://palash.dev/blog/building-with-ai/ #### Content ## Building with AI — Lessons from the Trenches Everyone's building with AI now. But there's a difference between demoing a ChatGPT wrapper and shipping an AI-powered product that users trust. Here are some lessons from building AI features in production. ## Lesson 1: Latency is a feature Users will forgive imperfect AI output. They won't forgive waiting 8 seconds for it. Every millisecond of perceived latency erodes trust. Techniques that help: - **Streaming responses** — show partial results as they generate - **Optimistic UI** — update the interface before the API responds - **Caching** — most AI queries cluster around common patterns - **Edge inference** — run smaller models closer to users ## Lesson 2: The prompt is the product Your prompt engineering is your product logic. Treat it like code: ```markdown # Bad: Prompt as afterthought "Summarize this article" # Good: Prompt as specification "You are a technical editor. Summarize the following article in exactly 3 bullet points. Each bullet should: - Start with a bold key insight - Be under 20 words - Focus on actionable takeaways, not descriptions Article: {content}" ``` Version your prompts. Test your prompts. Review your prompts in PRs. ## Lesson 3: Guardrails > Guidelines Don't *ask* the model to behave. *Force* it to behave: - Structured output with JSON schemas - Output validation before it reaches the user - Fallback responses when confidence is low - Rate limiting to prevent abuse ## Lesson 4: Show your work Users trust AI more when they can see *why* it made a decision. Add: - Confidence indicators - Source citations - "Edit this" buttons - Clear "AI generated" labels ## The bottom line AI is a tool, not a product. The product is the *experience* you build around it. Focus on the experience, and the AI will take care of itself. --- ## About Palash is an engineer, product builder, and systems thinker who makes developer tools, media platforms, and infrastructure that bridge low-level performance and high-level UX. **Core Stack**: TypeScript, Rust, Zig, Python, CUDA, Astro, React, Tailwind v4, Cloudflare Workers, Tauri **Links**: - GitHub: https://github.com/debpalash - Website: https://palash.dev - RSS: https://palash.dev/rss.xml - Humans.txt: https://palash.dev/humans.txt