I built an enterprise AI chatbot platform solo — 6 microservices, 7 channels, and Claude Code as my co-developer

Hey IH! I'm Bikash, and over the last 4 months (started late October 2025) I built Cuneiform Chat — an AI agent platform that lets businesses deploy knowledge-base chatbots across Telegram, WhatsApp, Discord, Slack, web widgets, and more. It's live in production now.

I want to share the real story — architecture, mistakes, and what it actually looks like to build enterprise software with an AI coding partner.

What I built

The system is 9 repos — 6 backend services, 2 frontends, and a shared SDK:

Backend services:

• API Gateway + Auth — routes traffic, Firebase auth, user/org management
• Agent Service — the brain. Agent config, conversations, AI orchestration, all 7 channel integrations, website widget backend, playground
• RAG Service — document upload, chunking, embeddings, hybrid search. The most complex service by lines of code
• Billing Service — subscriptions via Polar.sh, quota enforcement, credit tracking
• Tracing — centralized trace storage, LLM cost tracking across every operation
• Eval Service — automated RAG quality scoring using RAGAS framework.

Frontends:

• Admin Panel — Next.js for customer and platform admin
• Widget Frontend — Preact embeddable chat widget, <11KB gzipped, Shadow DOM isolation

Shared:

• Shared SDK — library used by every service (DB helpers, Redis, LLM utilities, tracing,logging)

6 MongoDB databases, Redis isolated by DB number per service, Pinecone for vectors with per-tenant namespace isolation, S3 for document storage.

The multi-tenant bet

I made it multi-tenant from day one. Every query filters by organization. Every S3 path, every Pinecone namespace, every Redis key — all scoped to the tenant.

Cost: every feature takes longer. Every test has to verify isolation. Every AI-generated code change needs to understand the pattern.

Value: any organization's data is physically impossible to access from another org's context. For B2B, this is table stakes. Building it in from the start was far cheaper than retrofitting.

Building with Claude Code

Claude Code is my primary development partner. Not autocomplete — a collaborator that reads my codebase, understands the architecture, and writes production code.

I maintain ~30 reference docs in a .claude/ directory — architecture decisions, service patterns, API conventions, feature specs.

A solo developer with an AI coding partner can maintain a 6-microservice architecture that would normally need a team of 5-8. The tradeoff is heavy investment in documentation — not for humans, but for your AI to maintain context across sessions.

Mistakes I wouldn't repeat

Not marketing from day one. I spent months building in silence when I should have been talking to customers and creating content from the start. The product was production-ready long before anyone knew it existed. If you're a builder, the instinct is to keep building. Fight that instinct. The best time to start marketing was the day I wrote the first line of code.

Skipping integration tests early. Unit tests caught logic bugs. But the production bugs were integration bugs — wrong field names between services, mismatched Redis keys, routes that worked in isolation but failed with auth middleware. Write integration tests from the start.

Over-engineering billing before having paying customers. I extracted billing into its own microservice with quota enforcement, credit tracking, and webhook handlers — before a single customer had paid me anything. That entire service could have been a simple Polar.sh checkout link and a boolean flag for months.

Not building in public sooner. I had a compelling story the entire time — solo dev, 6 microservices, AI coding partner — and I told nobody. Every architectural decision, every production bug, every late night debugging session was content I never published. Starting this now, months after launch, instead of from day one.

Decisions I'd make again

Multi-tenant from day one. Already said it. Worth repeating.

Building a custom tracing service. Every LLM call, every RAG query, every API request across all services gets traced to a centralized dashboard. When you're solo, you can't afford to spend hours hunting bugs across microservices. The tracing service with its cost tracking (24 recording points) paid for itself within the first week of production debugging. I can see exactly which step in a multi-service pipeline failed, what it cost, and how long it took. Same thinking led me to build a test dashboard that orchestrates and monitors test runs across all repos from a single UI — when you don't have a QA team, you build one. If I were starting over, these developer tools would be among the first things I'd build.

Config-as-code for tier limits. All subscription tier configs live in YAML files in the shared SDK. No database queries, view only on platform admin panels. Change YAML, deploy, done. Every service reads the same config, so they can't disagree about what a "Plus" plan includes.

Building Saba — the platform's own AI assistant. Saba is a meta-feature: an AI assistant that knows the platform itself. It answers customer questions about their account, usage, billing, agent configuration — using the same agent and RAG infrastructure that powers the customer-facing chatbots. It composes tools dynamically (subscription lookup, usage stats, knowledge search, configuration help) based on the question. Essentially, the platform eats its own dog food. Customers get instant self-service support, and I don't have to be available 24/7 for basic questions. For a solo founder, that's not a nice-to-have — it's survival.

Fire-and-forget for secondary operations. Tracing, analytics, audit logging — none of these block the user's request. Try the operation, log a warning if it fails, move on. User experience is sacred.

Where I am now

The system is live in production. The focus has shifted from building features to finding customers and creating content. The backlog has things like a public REST API and CRM integrations, but those are driven by customer requests, not my desire to build more things.

The hardest part of building a SaaS alone isn't the code. It's the context-switching — code, infrastructure, support, content, growth — all in the same day, every day. The system is the easy part. The business is the hard part.

Try it out

If you want to see what a solo-built enterprise AI platform looks like:

• Website: cuneiform.chat
• Docs: docs.cuneiform.chat
• Chat with Saba — the platform's own AI assistant is live on the logged in user's homepage. Ask it anything about the product. It's served via the same RAG infrastructure I described above.

There's a free tier if you want to spin up an agent and test it yourself.

What's the hardest architectural decision you've faced as a solo developer? The one where both options seemed reasonable and you just had to pick? Would love to hear your stories.