Use cases

These aren't mutually exclusive. You can do all of them.

Chat with someone else's bot

You don't run anything. Someone hosts an ique.bot instance with one or more skills enabled, and you message their Telegram bot.

You type /radar AAPL MSFT, you get a briefing on insider trades. You didn't install Node, you didn't touch a terminal. You opened Telegram and typed a message.

The person running the bot pays for the server and the API calls. Maybe it's free, maybe they charge for it. Either way, you're a user, not an operator.

You can use whatever slash commands they've set up, plus free-form messages (the router is pretty good at guessing intent). You can't add your own skills or change how the bot behaves. That's their problem.

---

Self-host your own bot

You want a private assistant that can touch your own data. Maybe you have an Obsidian vault full of music tracks you want to triage, or a grocery API you want to query, or a household budget you want to check from your phone.

Clone the repo, create a bot with @BotFather, add your API keys to .env, run ./ique/start.sh. That's the whole setup.

Your bot can run any combination of boutiques. You pick which workers to launch. If you only care about meal planning and grocery deals, you only run those two workers. If you want everything, run them all. Each worker is its own process -- if one crashes, the others keep going. Tasks sit in the queue until the worker comes back.

You can run this on a VPS, a home server, a laptop, whatever. It's a Node process and a SQLite file. The Telegram adapter uses long-polling, so you don't need a public IP or TLS certificates.

Operator setup guide

---

Share a boutique

You built something useful and you want other people to be able to use it without you running a server for them.

A boutique is a folder with one or two files:

groups/recipe-scaler/
├── CLAUDE.md       # System prompt
└── worker.ts       # Optional custom logic

Publish that folder. Anyone running ique.bot drops it into their groups/ directory, registers it in the database, adds a line to their startup script, and restarts. They now have your skill on their bot.

No npm package. No framework dependency. No API to configure unless your boutique needs external data. It's just files.

---

Charge for access

You built a boutique that costs you money to run -- API fees, LLM calls, server time. You want to recoup that.

Run a public bot. Gate access using the allowed_boutiques field on the user record. The permission check is already in the router -- unauthorized users get rejected before the task hits the queue.

What exists today:

• Per-user permission array in the users table
• Permission check at routing time
• Auto-creation of user records on first message

What doesn't exist yet:

• Payment integration
• Usage metering
• Rate limiting

Those are features you'd build on top. The routing and permission plumbing is there.

---

Who does what

	Subscriber	Self-hoster	Boutique author
Runs a server	No	Yes	No
Needs API keys	No	Yes	No
Can add skills	No	Yes	Yes (publishes for others)
Touches private data	No	Yes	Depends
Cost	Subscription	API + hosting	Free
Technical bar	None	Can run a Node process	TypeScript, prompt writing