Three bots sold. Two in Spain, one in Brazil. Total monthly revenue: $250.
That's not a headline. That's not a "we just closed our Series A" post. But it changed everything about how I think about this product.
The Product Before Sales
The Employees started as most side projects do — I built what I thought was cool. An AI employee platform: you pick a tier, we spin up a virtual assistant connected to Telegram, configured with your tools, running 24/7. Hosted, managed, ready to work.
The tech was fun. OpenClaw instances deployed as Docker Swarm stacks via SSH to a Contabo cluster. Odoo as the backoffice — subscriptions, provisioning, customer portal. Traefik routing. CI/CD pipeline. Auto-provisioning on purchase.
I had architecture. I had infrastructure. I had a pipeline that could deploy a bot in under 3 minutes.
What I didn't have was a single person paying for it.
What Happened When Someone Actually Paid
The first sale came from a solopreneur in Spain — a consultant who needed help managing client communications across WhatsApp and email. Standard tier, $50/month. The onboarding took 48 hours, mostly because I was manually tweaking the system prompt to match their workflow.
Then two more. A small dev shop in São Paulo that wanted a bot to triage GitHub issues and draft responses. A marketing freelancer in Barcelona who needed someone to monitor competitor Instagram accounts and summarize trends weekly.
Here's what I learned from those three sales:
1. The tech stack doesn't matter to customers. At all.
Nobody asked about Docker Swarm. Nobody cared about hexagonal architecture or that I migrated from Z.ai to OpenAI's GLM models for better cost efficiency. They asked: "Can it answer WhatsApp messages in Portuguese?" and "Will it know my clients by name?"
The conversation was never about infrastructure. It was about their specific workflow gap.
2. "AI assistant" means something different to everyone.
The consultant wanted a secretary. The dev shop wanted a junior developer. The marketing freelancer wanted a research analyst. Same product, same tier, completely different expectations.
This is the task-runner gap I hadn't anticipated. My platform provisions a general-purpose OpenClaw bot with a system prompt. But what customers actually need is a role — with domain knowledge, specific tools configured, and clear boundaries on what it should and shouldn't do.
The gap between "here's your AI bot" and "here's your AI employee" is entirely in the specialization layer. And that layer was manual, slow, and lived in my head.
3. Shipping > Building.
I spent weeks perfecting the auto-provisioning pipeline. The Odoo→Redis→Rust→dispatch chain. The ECOBIO review system. The drip email campaigns for trials. Infrastructure I'm proud of.
But the three sales came from direct outreach on Telegram. A personal message. A 5-minute voice note explaining what the bot could do for their specific case. No funnel. No landing page conversion. Just talking to people.
All that infrastructure is necessary — but it's table stakes. The thing that actually moves revenue is sitting down, understanding someone's problem, and showing them exactly how a bot solves it.
What Changed After
The first thing I did was kill features I was building and prioritize what paying customers needed:
- Skill templates by role. Instead of a blank system prompt, I'm building pre-configured roles: "Customer Support Rep", "Dev Triage Bot", "Social Media Monitor". Each comes with a tuned prompt, relevant tool connections, and example workflows. The customer picks a role, customizes the details, done.
- Model cost optimization. Standard tier bots were burning through OpenAI credits faster than $50/month justified. I migrated to tiered models —
gpt-4.1-nanofor standard,gpt-4.1-minifor professional. The point: cost-per-bot has to leave margin, or you're running a charity. - Onboarding as a product feature, not a service. Those 48 hours of manual prompt-tweaking? That should be a guided flow in the portal. Customer fills in their business context, picks a role template, the system generates a tailored prompt. Day-one value, not day-three.
The Numbers That Matter
Let me be honest about the economics:
- 5 bots active (3 paying, 2 pilots)
- Infrastructure cost: ~€4.50/month (one Contabo VPS)
- LLM cost: variable, but nano models keep it under $5/bot/month
- Revenue: $250/month
That's not quit-your-job money. But the unit economics work. Each additional bot is almost pure margin — the VPS handles dozens of instances, and the LLM cost scales with actual usage, not capacity.
The question isn't "can this be profitable?" — it's "can I get to 20 bots without needing a second server?"
The Provider Merry-Go-Round
This part deserves its own section because it's a lesson in how real infrastructure decisions get made — not in architecture meetings, but in Sunday afternoon debugging sessions.
We started with OpenAI. Solid models, predictable API, everyone knows it. But the per-token costs add up fast when you're running 5 bots 24/7. A standard-tier bot doing light conversation can burn through $5-8/month in API calls alone. On a $50/month subscription, that's 10-16% of revenue going straight to OpenAI.
Then Z.ai caught my attention. They offer GLM models — glm-4.7 and glm-5-turbo — with a subscription-based pricing model instead of per-token. For a fixed monthly fee, you get a generous allocation. For our use case (many bots, moderate usage each), the math was dramatically better.
So today I did the migration. Changed the ir.config_parameter records in Odoo, updated the tier-to-model mapping in code, pushed through CI, deployed, and reprovisioned all 5 bots. The whole thing took a few hours, including fixing an infrastructure bug where our deploy verification was still trying to hit a Swarmpit API with an expired token instead of just using SSH like the rest of the deploy pipeline.
That bug is the kind of thing you only find when you actually ship. The provisioning worked fine in isolation. The monitoring check was broken. The bot would deploy successfully and then get marked as "error" because the status check failed. Classic case of testing the happy path but not the verification loop.
The fix was simple: make check_deploy use the same SSH path as start_deploy. One consistent mechanism instead of two. Pushed, CI green, done.
The takeaway on providers: don't marry your LLM provider. Abstract the model selection behind a config layer (in our case, Odoo ir.config_parameter + a computed field on the bot model). When a better deal comes along — and it will, this market moves fast — you want to be able to switch in hours, not weeks.
Z.ai's subscription model makes the unit economics significantly better. Instead of watching per-token costs and hoping your bots don't get chatty, you pay a flat rate and plan around it. For a bootstrapped product with thin margins, that predictability is worth a lot.
What I'd Tell Past Me
Stop building infrastructure nobody asked for. Talk to 10 people before writing one line of code. Your first customer will teach you more than your best architecture diagram.
And when someone pays you $50/month for something you built — even if it's not perfect, even if you had to SSH into the server to fix their bot at midnight — that's not a bug. That's product-market learning happening in real time.
The provider switch taught me one more thing: the ability to change your mind fast is a competitive advantage. Today it was Z.ai. Tomorrow it might be something else. The point isn't picking the perfect provider — it's building a system where switching is a config change, not a rewrite.
Three bots. $250/month. A Sunday spent migrating LLM providers. Everything changed.
Omar Díaz builds AI-powered virtual employees at The Employees. Previously: Odoo consultant, backend engineer, and someone who learned that shipping beats building every time.