4 Alternatives to a Hosted Chatbot Subscription — and What Each Actually Costs

"Alternatives to X" pages usually turn into a ranked list of vendors with price badges that were stale before publication. This one is different: there are four routes, not four products, and the fourth route is "keep paying". We run a small AI support bot on our own VPS, so we have a stake in one of these answers — that is disclosed where it matters.

By "cost" we mean four separate things: cash, setup time, control, and who gets paged when it breaks. A route that wins on cash and loses on the other three is usually not the cheap one.

Route 1 — Write it yourself

For a low-traffic support widget, the whole thing is smaller than frameworks suggest. Our production shape:

one standard-library HTTP server on a loopback port
one systemd unit
one Caddy site block with SSE buffering disabled
one .env (mode 600, excluded from deploy archives)
one UTF-8 text file for the system prompt / knowledge base

No database, no queue, no container, no GPU — the model sits behind an API endpoint, so the server only does HTTP, SSE framing, quota counters, and prompt assembly.

You pay: an afternoon plus the debugging of four or five non-obvious things. Some keyless OpenAI-compatible endpoints accept stream:true and return HTTP 200 with no content deltas; the fix is to request the full text with stream:false and slice it into SSE chunks server-side. A reverse proxy that buffers responses collapses those chunks into one lump. A systemd Environment= line silently overrides the same key from EnvironmentFile=, which can leave a signing key and a verification key out of sync with no crash in the logs. And an inline comment on a numeric .env line turns a cap into NaN — every comparison fails quietly and the guardrail is simply off.

You get: total control over model choice, data location, quota behavior, and the failure path. Near-zero marginal cost if the default endpoint is keyless and caps are in place.

Don't pick it if: nobody will own the box, or you need to connect a paid key before you have written the caps. An uncapped paid key is worse than any subscription.

Route 2 — Buy a source kit and deploy it

This is the middle path: someone else has already hit the sharp edges and handed you the code plus the notes. A source kit is a one-time transfer of files, not a service. You run it on your infrastructure; there is no vendor runtime, no automatic entitlement, and no SLA.

You pay: a one-time amount, plus the same VPS and any optional model key. You still need terminal access and basic Python. What you are buying is the deletion of the debugging afternoon — specifically the regression tests for the guardrails, the deployment notes, and a compliance checklist.

You get: readable source you can audit before running, a license that says what you may do with it, and a fixed starting point. This is the route we sell, so treat the next paragraph as a disclosure rather than a recommendation: our kit contains a runnable server, setup and compliance documents, cost-guardrail regression tests, and no live credentials. Its price is on its own product page, not quoted here.

Check before you pay anyone: are secrets read from environment variables or hard-coded? Is the numeric config parsed explicitly and asserted at startup? Is there a test for the off-by-one trial counter? Is there a documented restart step for the knowledge base? A kit without those four is a zip file with a README. There is a 12-point checklist for exactly this.

Route 3 — Assemble an open-source stack

If you want retrieval over documents, an admin UI, multi-user editing, or connectors, mature open-source projects cover much more than a hand-written server does. You compose a chat framework, a retrieval layer, a model endpoint, and your own hosting.

You pay: integration time, dependency upgrades, and the model key. Component count is the real cost here — each piece has its own config surface and its own failure mode, and the composition is yours to test. This is also where a "free" stack quietly acquires a managed vector database and a monitoring bill.

You get: a community, a much wider feature set, and no single vendor's lock-in on the orchestration layer.

Don't pick it if: your actual requirement is "answer 20 fixed questions about my products". A text file beats a retrieval pipeline for that. Complexity that nobody asked for is a maintenance bill with no revenue attached.

Route 4 — Keep the subscription

This belongs on the list and it is not a consolation prize. Hosted products bundle the parts that are genuinely annoying to build: subscription billing, tax handling, automatic entitlement, team roles, analytics, audit logs, and an SLA.

You pay: a recurring fee and a ceiling you did not choose.

You get: someone else owns the 2 a.m. failure. If a broken widget during a launch costs more than a year of fees, this is the cheapest route on the page.

When it's right: more than one person edits answers; you need automatic payment activation; compliance requires audit trails; or nobody on the team wants terminal access. We say this while running a self-hosted bot ourselves, because the two situations are different.

Four routes, side by side

Three questions that pick the route for you

1. Do you need money to change hands automatically? If yes, route 4, or route 1–3 plus a separate payment-provider integration (which usually requires a business account). A static QR code collects payment but has no callback, so a person grants access by hand.
2. Is one person clearly responsible for the service? If no, route 4. A self-hosted service with no owner is a hosted service nobody maintains.
3. Do you already have a VPS and terminal access? If no, routes 1–2 now include learning server operations, and the total cost stops being "cheap".

If you answered no / yes / yes, routes 1 or 2 fit. The difference between them is whether you want to spend an afternoon rediscovering the four failure modes above. Both end in the same place: a bot on your box, a text file you control, and spend caps you tested yourself.