Vagmi Mudumbai, CTO
{
"name": "Vagmi Mudumbai",
"coding_since": 2002,
"role": "CTO for 14 years",
"track_record": "24 years building enterprise software",
"scaled": "$2M → $18M ARR",
"built": ["retailtech", "musictech", "logistics", "developer tools"]
}
But only the fearless can be great.
A runway-sized bet just to find out if the thing was worth building.
You no longer need to wait months or raise money just to test an idea. But you do need a system.
The person who knows the problem can finally build the solution.
The honest catch
Leverage cuts both ways. Today is about turning speed into safe progress
AI changed the speed, but not the principles.
The mental model to kill
“The agent writes
the code.” → Done.
Every stalled AI build starts here.
The agent is fastest at the part that was never the bottleneck.
Deciding what's right, and proving it's correct and safe, is the work now.
You cannot course correct the software as it is being built.
UI-first.
Architecture-led.
Validate every step
make it easy to adapt and evolve.
With the right guidance, an agent can iterate on software too.
We've solved this before
Small Teams. Fast Feedback. Working Software.
What I have been practicing since Thoughtworks.
Exactly what AI builders need now.
XP Practice · 01
XP Practice · 02
XP Practice · 03
XP Practice · 04
XP Practice · 05
Agents are infinitely fast,
infinitely junior pairs.
XP is the operating system for working with junior pairs at speed.
Discipline is what turns speed into trust.
The part builders miss most — because it's invisible until it isn't.
API keys and tokens committed “just to make it work.”
Checks that look right but miss a path.
One org reads another's data. The #1 SaaS killer.
SQL, shell — and prompt injection in your AI features.
Whatever package made the error go away.
All of it looks plausible.
That's exactly the danger.
My day job
I build secure sandboxes with V8 and microVMs.
So I think about two problems:
securing what the agent builds and,
securing the agent itself.
Guardrail 01
The user’s identity should come from their session — not from a field an attacker can change.
select … where org_id = session.orgId — the starter you'll build on today does this on every query.
Guardrail 02
Secrets live in the platform, never in a commit. Give the agent and the app the access they need, and nothing more.
Guardrail 03
Treat agent output like a confident junior's PR: review it, test it, run automated security review before you ship.
And sandbox the agent's own execution — it runs code too.
Security isn't a phase.
It's how you set up the work.
The template, the tests, the review loop — that's where safety lives.
Go slow to go fast.
Use serverless until it starts to hurt.
Dont burn money on DevOps.
No bill before you have users.
No servers to babysit at 2am.
Survive the day it actually works.
Most stacks make you choose. A builder shouldn't have to.
Serverless at the edge
No servers to babysit. Global by default.
You pay for
success, not for waiting.
Relational, on the edge.
Files & images — no egress fees.
Fast key–value reads, everywhere.
Coordination, sockets, presence.
Background jobs off the request path.
Run models next to your data.
One platform. One deploy.
Meet your starting capital
முதல் = the first · the capital
What you start with — and what you build on.
Today's stack
Auth, a typed multi-tenant database, billing wired and tested.
The principles from this talk.
The loop you'll practice
In an afternoon.
You need leverage, discipline, and a substrate that scales with you.
Empty repo → onboarded → deployed → your first feature. Follow along.
builders.vagmi.caStep 01 · GitHub
github.com/niraitech/mudhal ari (all lowercase, no CAPS recommended)
Step 02 · Claude
Create a .md file inside a prd folder for my following idea: (your idea) /onboard — then say yes to every question (Rename the App, Credentialed Setup)
Step 03 · Clerk
dashboard.clerk.com pk_test_… and Secret key sk_test_… Step 04 · Clerk
CLERK_PUBLISHABLE_KEY = pk_test_… · CLERK_SECRET_KEY = sk_test_… .dev.vars → set CLERK_SECRET_KEY and CLERK_PUBLISHABLE_KEY (leave CLERK_WEBHOOK_SECRET as-is — optional).env.local → set VITE_CLERK_PUBLISHABLE_KEY (same publishable key)
Step 05 · Cloudflare
dash.cloudflare.com/profile/api-tokens → Edit Cloudflare Workers → Use Template Step 06 · Cloudflare
CLOUDFLARE_API_TOKEN = your token
export CLOUDFLARE_API_TOKEN=<yourtoken> .env.local: CLOUDFLARE_API_TOKEN=<yourtoken> · test with npx wrangler whoami npx wrangler d1 create ari — answer y / enter to each prompt
Step 07 · Verify & deploy
I have setup the environment. Verify it. — say y to the questions
✅ Renamed app · ✅ Clerk keys in .dev.vars / .env.local · ✅ D1 created, id wired into wrangler.jsonc, migrations applied · ✅ doctor / typecheck / tests all green
Now deploy this to Cloudflare Yes allow for this project · for deploy say Yes Step 08 · First-time Cloudflare
workers.dev subdomain yet
shanthi → ari.shanthi.workers.dev), then re-run the deploy
pnpm run deploy yourself and answer yes at the prompt
Step 09 · Go live
https://ari.<subdomain>.workers.dev Clerk: A secretKey must be provided…, check the Cloudflare Observability section, then ask Claude: Set the required Cloudflare variables from my dev vars Step 10 · Save
Commit and push, then merge this to main Get the URL from cloudflare and set APP_URL CLERK_SECRET_KEY, CLERK_PUBLISHABLE_KEY, APP_URL · D1 migrated and bound
Step 11 · Roadmap
Continue with the roadmap docs/roadmap.md — mapped straight from your PRD into 8 phases, each a vertical slice that ends deployable and keeps pnpm test green
Commit roadmap, then Merge to main and push Step 12 · Build
Do Phase 1 pnpm run dev → Ports → mudhal dev (5173) Deploy to cloudflare (local can be flaky)