When your first 3 customers arrive before your product is "ready," you learn fast what actually matters.
The Moment That Changed Everything
We had 3 paying customers before we had a proper onboarding flow. Two in Spain, one in Brazil. Two different countries, two different languages, zero automation.
I was manually provisioning bots. SSH into a server, spin up a container, configure the LLM, paste a Telegram deep link into an email. Repeat.
It worked — until it didn't scale.
The question wasn't "how do we build a better bot." It was "how do we let someone who isn't us run this thing?"
Owner vs. Operator: The Split That Unlocked Scale
Here's the first design decision that actually mattered: separate the owner (the person paying) from the operator (the person using the bot daily).
Why? Because in most small businesses, the person who buys the tool isn't the person who uses it. The clinic owner buys 3 AI assistants — the receptionist, the appointment manager, and the patient follow-up bot are operated by different staff members.
Our initial flow assumed one person does everything. Wrong.
What we built:
- Owner purchases bots through the portal
- Each bot gets a unique activation link:
t.me/botname?start=TOKEN - Owner forwards the link to whoever should operate each bot
- Operator clicks, bot binds to their Telegram, done
No training sessions. No "schedule a call with our team." No 45-minute onboarding webinar.
The deep link IS the onboarding.
The Free Tier That Isn't Charity
Every SaaS has a free tier now. Most of them lose money on it and call it "marketing spend."
We did something different. Our infrastructure runs on Docker Swarm — the same cluster that powers our paid bots. Free tier bots share resources on the swarm. Paid bots get their own dedicated VPS.
The cost difference:
- Free bot: ~$0.50/month marginal cost (shared CPU, shared LLM quota)
- Paid bot: ~$80/month (dedicated VPS + LLM API + tools)
The free tier isn't a loss leader. It's a funnel with near-zero marginal cost. When someone's free bot hits the usage ceiling, upgrading is one click — and their bot keeps all its context and configuration.
No migration. No "export your data." Just more capacity.
Feature Flags for Bots (Not Code)
Here's something we stole from software engineering and applied to AI product management: feature flags, but for bot capabilities.
When we build a new skill for our bots — say, appointment rescheduling — we don't ship it to all bots immediately. We:
- Build and test internally
- Enable the flag for ONE customer's bot
- Run real conversations through it
- QA passes → flag on for everyone
This isn't revolutionary in software. But in the AI agent world, most people ship prompts directly to production and pray. We had a customer's bot hallucinate a discount policy that didn't exist. Once. That was enough.
Feature flags turned our bots from "deployed and forgotten" into "deployed and monitored."
The Revenue Sharing Model Nobody Talks About
We have partners selling our bots. Not affiliates with a referral link — actual salespeople who demo the product, close deals, and handle first-contact support.
The model is dead simple:
- We set the price on the website
- If a partner sells at that price or higher, the difference is theirs
- Monthly recurring: they get a proportional commission every month the client stays
Why this works: our partners aren't "promoting a product." They're building a book of business. The recurring commission means they care about retention, not just closes. They follow up. They check in. They become the face of the product for their clients.
We didn't plan this. Our first partner just asked "can I sell this?" and we figured out the model on a napkin. Three months later, it's our primary growth channel.
What We Got Wrong
LLM provider choice. We started with a Chinese API provider nobody had heard of. The tokens were cheap, but the reputation was a liability. "Who processes my data?" is the first question European prospects ask. We migrated to OpenAI — more expensive, but the trust factor alone closed deals that were stuck.
Over-engineering compliance. We spent two weeks researching GDPR levels, DPIA requirements, and §203 StGB for German medical practices. Our first 3 customers were in Spain and Brazil. They didn't care. We now have a simple rule: compliance follows revenue. When a German medical practice signs up, we'll build the compliance layer. Not before.
Assuming we needed a dashboard. Our MVP "Mission Control" was going to be a React app with real-time bot metrics, conversation logs, and analytics. What customers actually wanted was a Telegram message once a day: "Your bot handled 12 conversations today. 3 need human follow-up." That's it. The dashboard is still on the roadmap. Nobody has asked for it.
The Architecture of Delegation
If I had to distill what we learned into one principle:
Design every feature as if you won't be there when it runs.
- Onboarding → deep link, not a call
- Provisioning → automated, not SSH
- QA → feature flags, not "just ship it"
- Sales → partners with skin in the game, not marketing campaigns
- Compliance → follows revenue, not fear
Every decision that required us to be in the loop was a bottleneck. Every decision that didn't was a multiplier.
We're a two-person operation with bots in three countries. Not because we're brilliant, but because we designed for delegation from day one.
Well, day three. The first two days we were doing everything manually.