Home / Building / AI Lab & Failure Museum

The AI Lab.

Experiments in every state: shipped, half-built, abandoned, and still just ideas. Most AI pages show demos; this one shows process, because the abandoned ones taught me the most.

building

Giftonix: Multi-Tenant Rewards SaaS

The question: Can one codebase serve dozens of HR teams with per-client branding, milestone automation, booking windows, and role-based access without becoming a maintenance nightmare?

What happened: In progress. Three portals designed: landing page, admin portal, and client portals with per-client branding. Milestones trigger automated reminders and deals can be individually configured with booking windows. The architecture spec is 40 pages. The lesson so far: multi-tenant is easy to design and hard to maintain. Every client thinks their customization is the default. Building this taught me to ship one feature first and let users ask for more.

shipped

Portfolio Built with AI Coding Agents

The question: Can AI coding agents (Claude Code, Hermes delegation) architect and build a production portfolio site — Remix RR7 + Mantine + Sanity + MongoDB + Cloudinary — with a human steering design decisions and copy?

What happened: Shipped. This site is the result. Claude Code handled routes, components, Sanity schema, and Vercel config. I wrote the voice, the content, and every design decision. The agent was a fast typist, not a thinker. AI handled the scaffolding; I wrote the soul. The biggest lesson: AI is an excellent junior developer but a poor design director. Give it structure and it delivers. Give it taste and it copies someone else's.

See it live

shipped

NextEra AI: Enterprise UI at Scale

The question: Can one UI lead architect and ship five production SaaS products simultaneously for the US energy market, each with different branding, state regulations, and user flows?

What happened: Shipped and running in production. Chariot Energy, Atlantic Energy, Constellation EV, BKV Energy, and EnergyBot all live. Each has its own design system, enrollment flow, and state-based pricing logic. The challenge wasn't the code, it was the context switching. Five products, five codebases, five sets of business rules. Built reusable component libraries and established UI standards across teams. Chrome extensions, cross-platform apps, and analytics dashboards all shipped under this umbrella.

shipped

Hermes: Autonomous Daily Briefing Agent

The question: Could an LLM agent run autonomously on cron, track my Mac activity, capture window titles and browser tabs, and deliver structured daily briefings without human intervention?

What happened: Shipped and running daily for months. 9AM check-in, 7PM briefing, 9PM health check, Sunday weekly review. The agent SSHes into my Mac, reads activity logs, compares plan vs reality, and posts a daily briefing to Discord. The hardest part wasn't the LLM integration, it was teaching the agent to say nothing when there's nothing to say instead of inventing insights. An agent that knows when to stay quiet is more useful than one that always has an opinion.

shipped

AI Blog Pipeline: 38 Technical Posts

The question: Could an AI-assisted pipeline produce publication-ready technical blog posts at scale — from drafting to Sanity CMS to Vercel deploy — while maintaining a consistent, authentic voice?

What happened: Shipped. 38 posts published covering TypeScript, MongoDB, WebAssembly, AI trends, Bun, React patterns, and more. AI drafts reach ~70% quality. The last 30% — voice, the right anecdotes, the 'I tried this and here's what broke' honesty — can't be automated. Established a hard rule: an AI draft never publishes without a human edit pass.

shipped

DocPilot's AI Copilot

The question: Could an AI layer brief a doctor's morning, summarise any chart in seconds, and read practice analytics in plain language, without ever diagnosing or prescribing?

What happened: It shipped, live inside DocPilot. The hard part wasn't the model — it was the restraint. Every summary stays a summary. The deterministic product works without AI; AI only ever adds, never blocks. Built for Indian clinics where a prescription in ~30 seconds means a doctor leaves on time.

See it live

Failure Museum

The Failure Museum.

Twenty-plus projects taught me one thing above all: the failures pay the best tuition. This museum keeps them on display, not as confession, but so the lessons don't fade. Success stories are on the building page; this room is for the rest.

The exhibits below are real stories from real projects. Some stung. Some taught me something I still use every day. All of them are here because the lessons were worth more than the wreckage.

Exhibit 01

MongoDB to SQLite: The Migration I Abandoned

What was it? I replaced MongoDB with SQLite in a production side project to see if a single-file database could simplify deployment and cut costs. Why did I build it? MongoDB Atlas bills were climbing, and SQLite hype was peaking. Everyone was shipping SQLite in production. I wanted to know if it worked for real workloads. Why did it fail? SQLite was faster for reads — no network overhead, zero latency. But my analytics dashboard relied on MongoDB's aggregation pipeline for per-user stats, monthly trends, and cohort analysis. Rebuilding all of that in raw SQL was days of work for features MongoDB gives you free. The simplicity win didn't cover the feature loss. What it taught me: 'Use the right database' doesn't mean 'use the trendy one.' MongoDB earned its place. SQLite is for apps that fit in one process, not for dashboards with five years of data.

Exhibit 02

TypeScript 6 Migration: The Hype vs The Reality

What was it? I migrated a mid-size project to TypeScript 6 pre-release, chasing the promise of the Go compiler — 10x faster builds, native binaries, a new era. Why did I build it? The TypeScript 6 announcement was everywhere. Everyone was benchmarking, comparing, claiming it would change everything. I wanted to be early. Why did it fail? I'm putting 'fail' in quotes here — the migration itself shipped. But the Go compiler wasn't the revolution people promised. Build times improved, yes. But the real lesson was that I'd accumulated enough tech debt that a compiler rewrite exposed more problems than it solved. Loose types, skipped strict checks, implicit `any` everywhere. The compiler didn't fail me; I'd been failing the compiler for years. What it taught me: Tooling upgrades don't fix bad code. The TypeScript 6 migration was fine. Cleaning up the mess it found was the actual project — and that took three times longer.

Exhibit 03

The SaaS That Had Everything Except Users

What was it? An employee rewards platform. Multi-tenant, per-client branding, milestone automation, bulk import, role-based access. The architecture was beautiful. The spec document was 40 pages. Every feature an HR team could want. Why did I build it? I thought if I built the complete platform, users would come. Every competitor had gaps. I would have no gaps. Why did it fail? I spent months building features nobody had asked for. The first potential client didn't want 40 features. They wanted one: send a gift card on a work anniversary. I had that feature buried under three menus. The platform worked perfectly and solved problems nobody had confirmed yet. What it taught me: Build the one thing first. Ship it. Let users tell you what's missing. A product with one feature and real users beats a product with forty features and zero users. DocPilot exists because I learned this: prescription in thirty seconds, nothing else, and let doctors ask for more.

The other room has the wins.

the lab and the museum. mind the unfinished ideas.