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, 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.

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 — 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

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

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 — free, open source, self-hosted.

Your voice. Your hardware. Your studio.

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

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.

“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, 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 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

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%.

// 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

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:

# 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.