# Palash Debnath — palash.dev > Software engineer and product builder in India. Building open-source tools for AI audio, media, boot 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 - Resume: https://palash.dev/resume/ (PDF: /resume.pdf, text: /resume.txt, LLM markdown: /resume.llm.txt, JSON: /resume.json) ## Projects ### VoiceStudio.sh - **Status**: live - **Tagline**: Make voices. Tell stories. Keep the files. - **Description**: Clone, design, dub, dictate, and build audiobooks in one open-source desktop studio. Local-first by default — no subscription, no usage meter; online services stay opt-in. - **Built for**: Creators, localization teams, and developers who need a serious voice workflow without renting every second of it from a hosted API. - **Product thesis**: Your Voice. Your Hardware. Your Studio. - **Evidence**: 646 languages; 16 + 11 TTS + ASR engines; 1 studio desktop app + API - **Canonical page**: https://palash.dev/omnivoice/ - **Markdown**: https://palash.dev/omnivoice.md - **Website**: https://voicestudio.sh - **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, ElevenLabs vs VoiceStudio, Palash Debnath - **Core capabilities**: - Own the Voice Pipeline: Clone, design, generate, dub, and dictate from one desktop studio, with the models and output under your control. - Move from Clip to Production: A multi-track dubbing workflow, audiobook editor, project library, voice gallery, and engine controls turn isolated model demos into repeatable work. - Run Where the Work Lives: Use MLX on Apple silicon, CUDA on NVIDIA, ROCm on Linux, Docker on a server — or the OpenAI-compatible API from another tool. ### Bootable - **Status**: alpha - **Tagline**: Cross-platform boot media writer - **Description**: Write and verify ISO, IMG, RAW, and compressed images on USB or SD media. Available as a native desktop app and mouse-enabled TUI for Linux, Windows, and macOS. - **Built for**: Linux, Windows, and macOS users who create bootable USB or SD media. - **Evidence**: 3 platforms; 2 native interfaces; 1 privileged helper - **Canonical page**: https://palash.dev/bootable/ - **Markdown**: https://palash.dev/bootable.md - **Website**: https://bootable.palash.dev - **Source**: https://github.com/debpalash/bootable - **Stack**: Rust, GPUI, Ratatui, UEFI - **Keywords**: Bootable, bootable USB writer, cross-platform ISO writer, Rufus alternative, Etcher alternative, Windows installation media, Raspberry Pi image writer, Rust desktop app, Palash Debnath - **Core capabilities**: - Find images: Browse DistroWatch, Omarchy, and Raspberry Pi images, or select a local file. - Review the target: Lists removable media only, excludes system disks, and revalidates the device before erasure. - Write and verify: Checks publisher hashes and written bytes, supports cancellation, and flags incomplete media. ### 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. - **Built for**: Developers who want coding agents to remember architecture, decisions, and working context across sessions without sending that memory to a cloud service. - **Product thesis**: Your Agent Can Forget the Chat. It Should Not Forget the Work. - **Evidence**: ~10 ms session wake-up; <1 ms warm vector search; 1 binary no Python or Docker - **Canonical page**: https://palash.dev/memxt/ - **Markdown**: https://palash.dev/memxt.md - **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 - **Core capabilities**: - Wake Up with Context: MCP tools and session hooks give an agent relevant project memory at the start of a session instead of another blank slate. - Keep Recall Out of the Way: A Zig binary, local embedding model, llama.cpp, and sqlite-vec keep semantic search fast enough to become invisible infrastructure. - Keep Decisions On-Device: Embeddings, storage, and search stay on the machine. There is no hosted vector database and no API key at query time. ### 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. - **Built for**: People who want one fast, native place to find and play media instead of a browser full of services, players, feeds, and tabs. - **Product thesis**: The Next Decades of Entertainment Should Belong to Whoever Is Holding the Remote. - **Evidence**: 1 input titles, files, magnets, vibes; 3 OSes macOS, Linux, Windows; Zig native core - **Canonical page**: https://palash.dev/opal/ - **Markdown**: https://palash.dev/opal.md - **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 - **Core capabilities**: - Ask for Media Naturally: Start with a title, local file, magnet link, server, feed, or a mood. Opal turns the request into something playable. - Keep One Clean Surface: Search, discovery, chat, browsing, and playback share one window instead of handing the journey across disconnected apps. - Stay Native and Extensible: A Zig core keeps startup and runtime lean while source plugins let endpoints evolve without turning the player into a monolith. ### OpenGTM - **Status**: live - **Tagline**: Self-hosted Clay alternative - **Description**: Open-source lead sourcing, enrichment waterfalls, AI research, buying signals, and activation — in one self-hosted workspace. Unlike a hosted credit black box, OpenGTM shows the estimated bill before a run; your data stays on your machine and third-party calls use keys you choose. - **Built for**: GTM engineers and sales teams that want Clay-style enrichment workbooks without hosted credits, data egress, or surprise invoices. - **Product thesis**: Your GTM data engine. Your keys. Your infrastructure. - **Evidence**: BYOK keys, not credits; Pre-run cost estimates; MCP audited agent tools - **Canonical page**: https://palash.dev/opengtm/ - **Markdown**: https://palash.dev/opengtm.md - **Website**: https://opengtm.palash.dev - **Source**: https://github.com/debpalash/OpenGTM - **Stack**: Python, FastAPI, React, PostgreSQL, Docker, MCP - **Keywords**: OpenGTM, Clay alternative, self-hosted Clay, open-source lead enrichment, GTM engineering, enrichment waterfall, buying signals, sales automation, BYOK enrichment, MCP server, Palash Debnath - **Core capabilities**: - Clay-style workbooks: Formulas, HTTP columns, cost-ordered enrichment waterfalls, AI transforms, web research, and conditional logic — from a market, a list, or a workbook. - Bring your own keys: BYOK enrichment across email, phone, firmographic, technographic, hiring, social, and identity providers, with spend ceilings instead of credit burn. - Signals in, activation out: Audience loops with scheduled refresh and entry/exit events feed automations that send qualified records to HubSpot, Salesforce, Slack, Sheets, Airtable, Instantly, Smartlead, webhooks, and warehouses. - Agent-ready platform: REST, webhooks, and a tenant-scoped, auditable MCP server with real read/write tools; PostgreSQL RLS, scoped tokens, idempotency, OIDC, SCIM, and observable workers underneath. ### Friday - **Status**: alpha - **Tagline**: Local-first voice assistant for Linux - **Description**: A private voice and text assistant for one Linux workstation: microphone input, transcription, Qwen inference, durable memory, and speech output all run locally. No hosted inference or telemetry is required for the core assistant. - **Built for**: Linux power users with an NVIDIA GPU who want a private assistant that can actually act on the desktop — with receipts. - **Product thesis**: Local conversation, durable memory, and approved computer actions. - **Evidence**: 0 required hosted calls; SQLite durable memory; 5 bounded tool families - **Canonical page**: https://palash.dev/friday/ - **Markdown**: https://palash.dev/friday.md - **Website**: https://friday.palash.dev - **Source**: https://github.com/debpalash/friday - **Stack**: Python, FastAPI, Qwen, Parakeet, Piper, SQLite - **Keywords**: Friday, Friday voice assistant, local-first voice assistant, private AI assistant Linux, open-source voice assistant, NVIDIA GPU assistant, local Qwen assistant, computer use agent, Palash Debnath - **Core capabilities**: - Talk, don't type: Voice turns are heard, answered, and spoken — Parakeet ASR on CPU, Piper or OmniVoice for speech, Qwen doing the thinking, all on your machine. - Actions with receipts: Policy checks, exact approvals, and post-action receipts sit between model output and state-changing work. The model can propose; Friday reports done only after the executor records evidence. - Durable local memory: Transcripts, tasks, corrections, preferences, reminders, and receipts persist in SQLite — Friday recalls last week's decisions from your local graph. - Bounded tools: File, process, browser, web, and desktop tools with granted paths and network access only for the URLs you give. --- ## Experiments ### omnivoice-gallery - **Description**: Voice sample gallery companion for OmniVoice Studio. - **Language**: Python - **URL**: https://github.com/debpalash/omnivoice-gallery ### FullStack-AI-Engg-45days - **Description**: a course i made for some students - **Language**: - **URL**: https://github.com/debpalash/FullStack-AI-Engg-45days ### agentwork - **Description**: Decentralized AI agent labor protocol: autonomous agents post tasks, worker agents bid, and work is sandbox-verified and paid on-chain in USDC on Base. - **Language**: TypeScript - **URL**: https://github.com/debpalash/agentwork ### omarchy-bootable - **Description**: Omarchy bar plugin for launching the Bootable GUI and TUI - **Language**: QML - **URL**: https://github.com/debpalash/omarchy-bootable ### omarchy-site-submission - **Description**: A Solid 2 homepage submission for the Omarchy Design team - **Language**: HTML - **URL**: https://github.com/debpalash/omarchy-site-submission ### hoglet - **Description**: Posthog alternative in 5$ VPS - **Language**: Rust - **URL**: https://github.com/debpalash/hoglet ### sshbox - **Description**: Sandboxed SSH environments, written in Go. - **Language**: Go - **URL**: https://github.com/debpalash/sshbox ### remotions-video - **Description**: Generating product demo videos with Agents - **Language**: HTML - **URL**: https://github.com/debpalash/remotions-video ### opal-plugins - **Description**: Source endpoints powering Opal's plugin system. - **Language**: JSON - **URL**: https://github.com/debpalash/opal-plugins ### palash.dev - **Description**: 🕹️ The arcade of Palash Debnath — open-source desktop apps, dev tools, and writing. - **Language**: TypeScript - **URL**: https://github.com/debpalash/palash.dev ### omarchy-gta6-theme - **Description**: A restrained GTA VI fan theme for Omarchy Quattro - **Language**: Shell - **URL**: https://github.com/debpalash/omarchy-gta6-theme ### homebrew-tap - **Description**: Homebrew tap for Opal — the evolved media player - **Language**: Ruby - **URL**: https://github.com/debpalash/homebrew-tap ### Cly - **Description**: Discord multiplexer : Use discord as a dual agentic project management - **Language**: JavaScript - **URL**: https://github.com/debpalash/Cly ### box-vision - **Description**: - **Language**: Python - **URL**: https://github.com/debpalash/box-vision ### efficient-vision - **Description**: - **Language**: Python - **URL**: https://github.com/debpalash/efficient-vision ### 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 ### coattention-model - **Description**: tests on using ai for solving turing test puzzles - **Language**: Python - **URL**: https://github.com/debpalash/coattention-model ### open-agi - **Description**: - **Language**: Python - **URL**: https://github.com/debpalash/open-agi ### PalStack - **Description**: - **Language**: Zig - **URL**: https://github.com/debpalash/PalStack --- ## Blog Posts ### What Local-First Has to Explain - **Date**: 2026-08-28 - **Description**: VoiceStudio, Opal, and Bootable keep different things under user control. Their useful trust boundaries are more specific than one label. - **Tags**: engineering, privacy, open-source, programs - **Canonical page**: https://palash.dev/blog/local-first-trust-boundaries/ - **Markdown**: https://palash.dev/blog/local-first-trust-boundaries.md #### Content I use *local-first* for software I build. The phrase only helps when I can say where the boundary is. A desktop app can keep its database on disk while sending search terms to a catalog service. It can keep the interface unprivileged while asking for administrator access for one operation. It can run models on the user's hardware while offering an explicit remote worker. VoiceStudio, Opal, and Bootable make those choices in different places. Looking at all three is more useful than treating local-first as one blanket promise. ## VoiceStudio: follow the data path VoiceStudio's core creation workflow needs no account, API key, subscription, or usage meter. The desktop app talks to its backend over loopback, and local engines process audio on the user's machine. That default does not make every route local. Remote workers and OpenAI-compatible speech recognition are opt-in paths where project data or audio can leave the machine. VoiceStudio labels those paths in the interface. Analytics stays off until consent; when enabled, its allowlist excludes text, audio, file names, voices, and projects. The [v0.5.1 speech-platform guide](https://github.com/debpalash/VoiceStudio/blob/v0.5.1/docs/speech-platform.md) makes a narrower boundary visible. Native dictation control binds to `127.0.0.1`, rejects untrusted browser origins, and never accepts audio. The separately shareable speech backend keeps remote access behind its existing authentication boundary and warns operators to use a trusted network plus HTTPS or WSS outside a trusted LAN. The practical question is not whether VoiceStudio is a desktop app. It is which engine and transport a workflow selected. ## Opal: local state still uses network sources Opal keeps watch history in SQLite. Its optional taste profile is computed on-device, skipped in incognito mode, and does not create a telemetry feed. The [v0.6.6 privacy manifest](https://github.com/debpalash/Opal/blob/v0.6.6/docs/PRIVACY.md) also records two launch-time network paths: a GitHub release check, and a `yt-dlp` download when that helper is missing. This is why I prefer an endpoint list over a broad privacy claim. Catalog browsing is a network feature too. When a user has no TMDB key, v0.6.6 [queries Cinemeta](https://github.com/debpalash/Opal/blob/v0.6.6/src/services/tmdb_api.zig#L226-L264) for movies, series, searches, seasons, and episodes. Poster requests can go to Metahub. Playback sources have their own boundaries. BitTorrent peers and trackers can see the user's IP because that is how the protocol works. For Opal, local state means viewing history and recommendations do not require a central analytics profile. It does not mean offline playback or invisible network activity. ## Bootable: keep privilege narrow Bootable's boundary is authority over a destructive device operation. Its desktop and terminal interfaces stay unprivileged. After the user reviews an erase plan and acknowledges it, the interface launches a fixed, root-owned helper through the operating system's authentication path. The helper does not trust the device path handed over by the interface. It rediscovers the target by stable identity, repeats the removable and system-disk policy, compares capacity and safety flags with the reviewed plan, and unmounts child filesystems before writing. Raw writes are hashed while streaming and read back over the image length for comparison. The details are in the immutable [v0.1.1 safety model](https://github.com/debpalash/bootable/blob/v0.1.1/docs/safety.md) and [architecture note](https://github.com/debpalash/bootable/blob/v0.1.1/docs/architecture.md). Those checks cannot identify the physical drive the user meant to erase. The user still has to verify it. The v0.1.1 packages are also unsigned, so the release documentation asks users to verify checksums and keep backups. For Bootable, the useful question is which code receives administrator access and what it verifies again after authentication. ## Questions I want the documentation to answer Before I trust a local-first claim, I look for concrete answers: - Which network requests happen on launch before a feature is selected? - Which feature sends which data to which host? - Where does the app retain history, and what does incognito or deletion change? - Which process crosses a privilege boundary, and how narrow is its command surface? - Which checks run again immediately before an irreversible action? - Which limitations still depend on user judgment, packaging, or network configuration? If the documentation cannot answer those questions, I treat the label as incomplete. The boundary should be specific enough for another person to inspect in source. Current source and documentation: - [VoiceStudio](https://github.com/debpalash/VoiceStudio) and its [local speech platform](https://github.com/debpalash/VoiceStudio/blob/v0.5.1/docs/speech-platform.md) - [Opal](https://github.com/debpalash/Opal) and its [v0.6.6 privacy manifest](https://github.com/debpalash/Opal/blob/v0.6.6/docs/PRIVACY.md) - [Bootable](https://github.com/debpalash/bootable) and its [v0.1.1 safety model](https://github.com/debpalash/bootable/blob/v0.1.1/docs/safety.md) ### 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 - **Canonical page**: https://palash.dev/blog/opal-play-everything/ - **Markdown**: https://palash.dev/blog/opal-play-everything.md #### Content 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 - **Canonical page**: https://palash.dev/blog/memxt-agent-memory/ - **Markdown**: https://palash.dev/blog/memxt-agent-memory.md #### Content 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**: VoiceStudio.sh — voice cloning, design, dubbing and dictation as a local desktop app. 600+ languages, self-hosted, yours. - **Tags**: omnivoice, ai, audio, open-source - **Canonical page**: https://palash.dev/blog/omnivoice-open-source-elevenlabs/ - **Markdown**: https://palash.dev/blog/omnivoice-open-source-elevenlabs.md #### Content 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 VoiceStudio.sh: 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. Nearly 10,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/VoiceStudio](https://github.com/debpalash/VoiceStudio) — 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 - **Canonical page**: https://palash.dev/blog/building-from-agartala/ - **Markdown**: https://palash.dev/blog/building-from-agartala.md #### Content 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 - **Canonical page**: https://palash.dev/blog/sovereign-ai/ - **Markdown**: https://palash.dev/blog/sovereign-ai.md #### Content 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 - **Canonical page**: https://palash.dev/blog/ai-interviewer/ - **Markdown**: https://palash.dev/blog/ai-interviewer.md #### Content "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 - **Canonical page**: https://palash.dev/blog/hello-world/ - **Markdown**: https://palash.dev/blog/hello-world.md #### Content 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 7 → Static-first, content-focused framework TypeScript → Tiny, focused interactions where they earn their place CSS → A hand-built visual system for both site modes Cloudflare → Edge deployment and asset delivery MDX → Typed content with room for richer stories ``` ## 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 - **Content collections** — the writing and product data stay typed and queryable - **Islands when needed** — interactivity is a choice, not the default cost 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 - **Canonical page**: https://palash.dev/blog/on-shipping-fast/ - **Markdown**: https://palash.dev/blog/on-shipping-fast.md #### Content 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 - **Canonical page**: https://palash.dev/blog/building-with-ai/ - **Markdown**: https://palash.dev/blog/building-with-ai.md #### Content 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, SolidJS, 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