We Built Intercom Before We Built a Chat Widget

In late 2025, Claude and I set out to build the ultimate customer experience platform. We called it DEBLO Intelligence -- the "world's first omniscient AI-Mesh CxPaaS platform." We were going to replace Intercom, Zendesk, Freshdesk, HubSpot, Slack, Notion, Google Workspace, and Jira. With one product. Powered by six AI models running simultaneously through a single intelligent core.

We built a 3,318-line landing page. We designed a dashboard with 17 modules. We modeled 50+ AI agents with personalities. We wrote a schema with 25 relationships across 15 database tables. We created a 4-column LiveChat interface that tracked customer sentiment, lifetime value, churn risk, and upsell opportunities in real-time.

We had 4 working API routes.

The launch date -- December 1, 2025 -- came and went. The project sat untouched for months. We never shipped a single thing to a single user.

Then, this week, I built an AI helpdesk widget for sh0.dev in one afternoon. Nine files. Two database tables. One streaming endpoint. It works. It is live. Visitors are using it right now.

This article is about why one approach failed and the other succeeded, and what I plan to do about it.

What We Actually Built

The project that became 0seat.dev (originally DEBLO Intelligence) lives in a monorepo with three apps: an API, a dashboard, and a public marketing site. Here is an honest inventory of what exists.

The API (ElysiaJS + Bun + InstantDB)

What works: - Magic code authentication (generates a 6-digit code, verifies it, issues a JWT) - SMS provider management (CRUD for admin, listing for tenants) - SMS sending (validates config, checks limits, creates a message record) - Health check

What does not work: - The magic code is logged to console. No email is sent. - SMS sending is simulated. No provider API is called. - There is no conversation endpoint. No message endpoint. No contact endpoint. No campaign endpoint. - The 15-table schema defines conversations, messages, AI contexts, AI analyses, AI responses, AI feedback, campaigns, daily metrics, AI metrics -- none of which have API routes.

Four routes. Fifteen tables. The data model was designed for a product that did not exist yet.

The Dashboard (Solid.js + Tailwind)

What works: - A stunning dashboard home with 17 module cards showing live-updating metrics - A unified inbox with 3-column layout, conversation threading, and AI suggestions - An AI LiveChat page with 4-column layout, multi-model agent tracking, customer intelligence panel - An approval workflow page with AI-powered recommendations - Dark mode, lazy loading, plugin system, responsive design

What does not work: - Every number on every screen is hardcoded. The metrics update every 3 seconds -- they generate random numbers, not real data. - The inbox shows mock conversations with mock messages from mock customers. - The AI LiveChat tracks "Claude Sonnet 4: 89 active, 94% success" -- these are string literals. - Seven modules are placeholder pages with a single paragraph of description text. - There is no API integration. The dashboard does not fetch from the API. It does not write to InstantDB. It is a static prototype that animates.

The Marketing Site (Solid.js + Tailwind)

What works: - Five complete marketing pages: home, pricing, how-it-works, AI agents, AI-Mesh architecture - A floating AI assistant with keyword-based responses (not real AI -- pattern matching) - A prelaunch modal that captures emails to localStorage - Four pricing tiers ($0 / $49 / $299 / $499) - Dark mode, responsive design, professional typography

What does not work: - The "2,847 AI Decisions Made Today" counter increments randomly every 2 seconds - The "Join 847 companies already on the list" is a hardcoded string - Emails are stored in localStorage. They go nowhere. - The AI assistant matches keywords and returns canned responses. No LLM is called.

Why This Happened

I am not going to blame scope creep as if it were something that happened to us. Claude and I did this to ourselves. Here is how.

The Vision Trap

We started with a legitimate insight: businesses in Africa use 10+ tools to manage customer communication. WhatsApp for chat. SMS for notifications. Email for formal communication. Spreadsheets for tracking. Separate tools for each channel, each with its own login, its own AI, its own monthly bill.

The idea was to unify everything. One platform, one AI, one bill. That is a real problem with a real market.

But instead of building the one thing that would prove the idea -- a live chat widget that actually works -- we built the marketing site that would sell the finished product. We designed the dashboard that would manage all 17 modules. We modeled the database that would store every type of data the platform would ever need.

We built the brochure before we built the product.

The Feature Gravity Problem

Once you have a 17-module dashboard on your screen, every module pulls you in. "The inbox looks great, but it needs real conversations. But conversations need contacts. But contacts need a CRM. But the CRM needs campaigns. But campaigns need SMS. But SMS needs provider management."

Each feature justified the next. The dependency chain grew in every direction. We were always one feature away from being able to demo something real.

After months of work, we had zero users, zero real data, zero validated assumptions, and a 3,318-line landing page promising things we could not deliver.

The Aesthetic Seduction

I will be honest about this: the dashboard looked incredible. The 4-column LiveChat interface with sentiment tracking and churn prediction was the most beautiful thing Claude and I had ever built. Every time I opened it, I felt like we were building something important.

That feeling was the trap. The aesthetic quality of the prototype created a false sense of progress. We were not making progress. We were making pixels.

What Changed This Week

This week I needed a helpdesk for sh0.dev. The instinct was to look at the 0seat.dev codebase -- surely we could extract the LiveChat module and ship it.

I opened the code. The LiveChat module was 800+ lines of Solid.js rendering hardcoded mock data. It depended on @deblo/ui-kit, @deblo/contexts, @deblo/plugins, @deblo/ai, @deblo/instant-client, and @deblo/shared-components. It could not be extracted without the entire monorepo.

So I built it from scratch. In one session. For sh0.dev.

The comparison is instructive:

The sh0.dev helpdesk is worse in every dimension except the one that matters: it works. Real visitors type real questions. A real AI generates real answers. Real conversations are stored in a real database. A real admin can read real transcripts.

The Plan: 0seat.dev in 7 Days

The 0seat.dev codebase is not worthless. The data model is thoughtful. The UI components are well-designed. The multi-tenant architecture is sound. What is missing is discipline about what ships first.

Here is what 0seat.dev needs to launch in 7 days:

Day 1-2: The Widget An embeddable JavaScript widget that any website can add with one <script> tag. It opens a chat panel, sends messages to the 0seat API, and streams AI responses. This is the sh0.dev helpdesk widget, extracted and made tenant-aware.

Day 3-4: The Inbox The existing inbox UI, stripped of mock data and connected to real API endpoints. An agent logs in, sees real conversations from real visitors, can read transcripts and respond. Two database tables: conversations and messages. Nothing else.

Day 5: The Onboarding A tenant signs up, gets an API key, gets a widget embed code. They paste it on their site. Conversations start flowing. That is the entire onboarding.

Day 6: Billing Stripe integration. Free tier with limits. Paid tier without limits. Usage-based billing on AI tokens. Nothing more.

Day 7: Launch Deploy. Announce. Get the first 10 paying customers.

Everything else -- campaigns, approvals, tasks, notes, mail, sheets, presentations, drive, 50 AI agents, multi-model routing, sentiment journey tracking, churn risk detection -- is post-launch. Not post-MVP. Post-launch. These features get built when customers ask for them, not when I imagine they might want them.

The Lesson

The lesson is not "start small." Every founder knows to start small. The lesson is that aesthetic quality is not product quality. A beautiful prototype with mock data is not 80% of a product -- it is 0% of a product. The last 20% is not polish. The first 20% is making something real.

Building the sh0.dev helpdesk in one afternoon taught me more about what 0seat.dev needs to be than months of designing the perfect dashboard. The constraints were instructive: no auth (it is public), one model (Haiku, cheapest), one endpoint (POST /api/ai/helpdesk), one component (HelpdeskWidget.svelte). Every constraint forced a decision. Every decision moved the product forward.

0seat.dev does not need 17 modules. It needs one widget that makes a visitor's question disappear and one inbox that shows a business owner what their visitors are asking.

Everything else is a feature request from a customer we do not have yet.

The 0seat.dev refactoring plan is published here. It contains the day-by-day implementation plan, the tech stack decisions, and the exact scope for the 7-day launch.