Launched invioTrack - a Telegram invoicing bot for freelancers. No app, no card fees
Soft launch from Chicago. ~3 months of evenings to get here.
What it is
A Telegram bot that sends invoices. You chat with it, it generates a clean PDF, it tracks who paid and who didn't, and it pings you (not your client) when an invoice goes overdue. No app to install — it lives in Telegram, which you already have on your phone.
What it deliberately ISN'T
It doesn't process your client's payment. There's no "pay with card" button inside the invoice. The freelancer collects the money on whatever rail they already use — bank transfer, Zelle, PIX, cash, Stripe link, whatever. The bot just generates the PDF and tracks status.
I get pushback on this from people who assume payment processing = the whole point of an invoicing tool. My answer: the moment I touch the freelancer's customer's money, I become a money transmitter (licensing, KYC, chargeback liability, fraud risk). I'm a solo founder. I can't carry that. And freelancers already get paid on rails they trust — what they actually struggle with is remembering to invoice and remembering to chase slow payers. That's the part the bot fixes.
Three rules I committed to
- No client-facing checkout. You keep your rails.
- No app to install. Telegram is the UI.
- No AI hype. It's a rule-based bot. Reminders fire on a schedule. The numbers add themselves up.
Pricing
- Free: 3 invoices/month, 2 clients
- Pro: $20/month — unlimited invoices + clients
- Business: $40/month — custom branding + CSV export
Languages: English, Spanish, Portuguese.
Stack: Python + python-telegram-bot, FastAPI for the Stripe webhook, SQLite + Litestream for backups, Caddy for HTTPS, Hetzner CPX21 (€8/mo). Stripe handles subscription billing only.
Where I'm honestly worried
- Onboarding. Chat UI is fast for builders but unfamiliar for non-techies. First invoice always works, but I'm not sure the "tap PDF → Share → email app" handoff is intuitive enough.
- Discovery. Telegram bots don't have an App Store. SEO, build-in-public posts, and word-of-mouth are it.
- Free tier may be too generous. 3 invoices/month is enough for a side-hustler to never upgrade.
Numbers I don't have yet: 0 paying customers. Live for 3 weeks. This launch post is part of finding the first ones.
Try it: @invioTrack_bot · Site: inviotrack.com
If you spin it up, I'd love a one-line "this worked / this broke" reply. Especially interested in: does the share-PDF flow feel obvious, or did you get stuck after the bot sent you the PDF?
The no-payment-processing decision is exactly right — money-transmitter licensing would bury a solo founder, and you clearly understand that. But it's also your hardest positioning problem, because the buyer doesn't know about money-transmitter law. They see Wave and Invoice Simple with "pay now" buttons and read yours as missing a feature, not making a smart legal choice.
The fix: don't position around what it doesn't do. Lead with the actual pain — remembering to invoice and chasing slow payers. "The bot that chases your overdue invoices so you don't have to" is a sharper hero than anything mentioning payment rails. Bury the no-checkout thing in the FAQ where the few who ask can find it.
On your free-tier worry — you're right it's too generous, but the fix isn't fewer free invoices. It's gating on clients/complexity, not invoice count. The upgrade trigger should fire when a side-hustler becomes real (5+ clients, can't track them), not at invoice #4. Gate the thing that correlates with "this is now my business."
On the share-PDF flow you asked about — that handoff is exactly the friction you fear. The whole pitch is "lives in Telegram, no app," then it punts to the email app for the most important step. Close the loop inside Telegram: collect the client's email once, have the bot send the invoice directly. Don't make the user do the share-sheet dance for the thing the product exists to do.
This is a smart constraint, especially avoiding payment processing. A lot of invoicing tools try to own the money flow too early, but your real wedge is simpler: help freelancers remember, send, track, and chase invoices without adding another app or financial workflow.
The strongest positioning might be “freelancer admin from chat,” not just Telegram invoicing. That keeps the product in the freelancer’s favor: low friction, no client checkout, no extra payment rails, no heavy accounting software.
One thing I’d pressure-test early is the name. invioTrack explains invoice tracking, but it also makes the product feel narrow and utility-like. If this expands into reminders, recurring invoices, client records, CSV export, branding, overdue workflows, and maybe other freelancer admin tasks, the name may start feeling smaller than the product.
A broader name like Xevoa .com would give the same product a cleaner workflow brand without changing what you’ve built. The product’s advantage is simplicity, but the brand still needs to feel trustworthy enough for freelancers to run real client money-adjacent work through it.
Really appreciate this — and the "freelancer admin from chat" framing is sharper than my own pitch. Stealing that.
On the name: I've been wrestling with the same thing. invioTrack was deliberately narrow because the wedge needs to be obvious — freelancers don't search for "admin tools," they search for "how to send an invoice without QuickBooks." The narrow name reduces decision friction when someone lands on the site.
But you're right that it becomes a ceiling if I add reminders, client CRM, expense tracking, etc. My current bet: ride the narrow brand to first $1-2K MRR, then either (a) rebrand at scale or (b) launch the broader product under a parent brand and keep invioTrack as the "starter" SKU. Renaming pre-revenue feels like polishing the door of a house with no plumbing.
One question back at you: if you were positioning this from scratch, what would you call the broader category? "Freelancer admin" is the frame — but is there a snappier 2-word handle for it that doesn't already belong to someone (Bonsai, HoneyBook, etc.)?
I’d avoid “freelancer admin” as the final category label. It is accurate, but it sounds a bit like back-office chores.
The sharper handle is probably:
“Freelance ops from chat”
or, if you want it to feel more client/payment-adjacent:
“Client ops for freelancers”
That gives you more room than invoicing without becoming vague. It can hold invoices, reminders, overdue follow-ups, client records, recurring work, exports, and lightweight admin, while still staying close to the freelancer’s real pain.
I agree with your sequencing: invioTrack can stay as the wedge.
The thing I’d separate is rebranding later vs controlling the broader brand option earlier.
If the plan is eventually:
invioTrack as the starter SKU
broader parent brand for freelancer workflows
then Xevoa.com is worth pressure-testing as that parent-brand layer. It has the workflow/platform feel without locking you into invoices, payments, or accounting software.
You do not need to rename pre-revenue. But if Xevoa is the kind of name you could see carrying the broader product, it is better to discuss that before more pages, users, and product memory build around invioTrack alone.
I control Xevoa.com, so if it is a real candidate for the parent-brand direction, happy to discuss privately and keep the acquisition side founder-friendly.
"Client ops for freelancers" is sharper than anything I had — taking that.
On the parent-brand question: I think it's a real consideration but the wrong time. I'm pre-revenue and trying to validate the core wedge first. Buying a parent-brand domain right now means I'm spending money to solve a problem I don't have yet. If I hit the point where I'm shipping a second product line under the same roof, I'll revisit it then with actual data on which direction the product is naturally growing.
Appreciate the offer to discuss Xevoa specifically — I'll keep it in mind for that future conversation, but for now I want to ride invioTrack to its first paying users and let the product tell me what the parent-brand should be.
Genuinely useful thread. Thank you for the time.
That makes sense. First paying users should stay the priority.
But I’d separate three decisions:
I agree you should not rebrand pre-revenue.
The risk is that if invioTrack starts working, you may quickly move into reminders, client records, overdue workflows, recurring invoices, exports, and lightweight freelancer admin. At that point, “client ops for freelancers” becomes the real category, but the broader brand decision has to happen under more pressure.
That is why I would not treat Xevoa only as a future idea.
If Xevoa is not the direction, no issue.
But if you can genuinely see it as the parent brand for the broader freelancer workflow layer, the cleaner move is to control the option now without forcing a rebrand today.
I control Xevoa.com. If the full acquisition feels too early, we can keep it lighter: a simple founder-friendly hold/reservation so you are not starting from zero if invioTrack gets traction and the parent-brand question becomes real.
That lets you keep focus on first paying users while still protecting the stronger brand path before more product memory builds around invioTrack alone.