We built four chats. Obviously, that was the sensible thing to do.

Whenever a developer runs into a problem, the first question is not always “How do we solve it?” Often it is “What are we going to solve it with?” Build it ourselves, or use something already built? Open source, or a hosted service?

Today, if you have AI, the answer seems obvious:

“Build it ourselves! Ourselves, ourselves!”

And why not? Why drag home some old, heavy, slow contraption, built twenty years ago—practically in the age of mammoths—when AI can produce a shiny new one before lunch?

We had that choice in front of us. In retrospect, this is the comparison we should have made before enthusiastically opening the editor:

Option	What it brings	Public price (USD)	The small print / “weight”
Build it ourselves	Exactly the hotel FAQ flow we wanted; no inbox or support suite we did not need	No vendor fee; developer time sold separately (apparently)	Every bug, integration, update and future feature comes home with you
Chatwoot	Open-source, self-hostable live chat and shared inbox; API and webhooks; optional AI features	Community self-hosted edition: $0 for the software. Cloud plans start free; paid plans are per agent	“Free” still needs Linux, PostgreSQL, Redis, and a production server. For production, Chatwoot recommends at least 4 GB RAM and 2 CPU cores.
tawk.to	Hosted live chat, ticketing and knowledge base; AI Assist available	Widget: $0. Remove branding: $29/month. AI Assist: from $29/month	A very persuasive “why build this?” price. You still need to check which extras and workflows your use case requires.
Crisp	Hosted chat and shared inbox; higher tiers add workflows, ticketing and AI tools	Free: $0 (2 seats); Mini: $45/month per workspace; Essentials: $95; Plus: $295	Workspace pricing, not per agent. The amount buys a broader support platform, not just a chat bubble.
Intercom	Messenger, shared inbox, help center, automation and Fin AI agent that can take actions on external systems	Essential: $29/seat/month; Advanced: $85; Expert: $132, plus $0.99 per Fin outcome	Seat cost plus AI outcomes. Excellent if you need that customer-service platform; a lot to adopt just to answer “Does the room include breakfast?”

This is a snapshot of public prices and product descriptions checked on October 16, 2026, not a universal benchmark. Plans, billing terms and included quotas change; the linked vendor pages are the source of truth. Chatwoot's Community code is MIT-licensed; its self-hosting guide documents the server requirements.

And before anyone asks: no, this is not a bundle-size comparison. These vendors do not publish directly comparable widget JavaScript sizes on the cited pages. “Heavy” can mean downloaded bytes, a dashboard with a small city inside it, an invoice, or the operational burden of keeping Postgres and Redis happy. We did not measure all those things, so we will not invent a kilobyte column to make the table look more scientific.

One thing we can measure, though: the embeddable widget script that ends up running on a hotel’s or a taxi company’s website is plain JavaScript, with zero npm packages pulled into the visitor’s browser. Not “minified to feel light”—there is simply no dependency tree to minify. We cannot audit anyone else’s supply chain, so we will not claim the competition is insecure. We can say that our widget has no third-party code to go wrong, which is a smaller, quieter kind of security than a vendor’s compliance page, but a security property all the same.

Also, we did not actually complete this spreadsheet before building. We had a small, concrete need and wanted a small, concrete widget. The spreadsheet is the responsible version of the story; the real version is that we started coding and only later noticed the pattern.

The small problem that started it

We had a problem with our hotel websites: tourists were having to navigate them.

They wanted to know the price, what was included, whether there was a transfer. The answers were on the site, of course. Somewhere. Usually behind a menu, a page, and a small but meaningful test of one's determination.

We did not want to bring in a large, opinionated component just to answer “How much is the room?” So we made a little chat for our quick hotel sites. Put it on the page, give it the basic information, let the tourist ask in ordinary language. No grand strategy. No platform roadmap. Just fewer clicks between a question and an answer.

This is how many grand strategies begin: by insisting there is no grand strategy.

Meanwhile, in three other parts of the codebase…

We were also building a taxi service. Passengers needed a way to talk to drivers.

We were building a financial application. Customers needed support.

And we were still building hotel sites, where that first little chat seemed like a pretty good idea.

These projects did not politely line up and wait for one another to finish. They were happening in parallel. Which is a productive way to work, right up until you look around and discover that you are developing four chats at once.

Four chats. Each one better than the other three. Naturally.

That sentence should make an engineer reach for the fire alarm. We did not have one handy, so we reached for the architecture.

The usual copy-paste strategy was working perfectly

By “perfectly,” we mean every chat was improving—and none of them was improving in quite the same way.

One had picked up a useful interaction. Another had better handling for its particular workflow. A third had learned something about support. Fix a small thing in one, and the other three remained serenely unaware. They were not broken; they were simply becoming four separate answers to the same question.

Copying fixes between them was possible. So is maintaining four calendars by sending yourself increasingly stern emails. Possible is not the same as a plan.

The important realization was that the products did not need the same behavior. They needed the same chat component—with a way for each host application to supply its own behavior.

One chat, not one-size-fits-all

We pulled the shared parts behind one embeddable interface. The host application still owns its data, business rules and decisions. The chat provides the conversation surface and can be configured to fit the job.

For a hotel site, the starting point is deliberately boring:

<script src="https://chat.fodylabs.com/chat-engine.js" defer></script>
<script>
  window.addEventListener('load', function () {
    ChatEngine.mount({
      endpoint: 'https://chat.fodylabs.com/api/chat',
      historyEndpoint: 'https://chat.fodylabs.com/api/history',
      title: 'Ask us anything',
      payload: { project: 'YOUR_PROJECT_ID', key: 'pub_YOUR_PUBLIC_KEY' }
    });
  });
</script>

Those two placeholders are the project's identifiers, not magic credentials you have to invent. In the FodyChat dashboard, create a project, add its FAQ or other knowledge, and copy the generated embed snippet. It supplies the project's ID and its pub_… public key. The ID tells FodyChat which project's settings and knowledge to use; the public key identifies that project when the widget calls the API. It is meant to appear in the page source, so it is not a password or secret. The project also needs to allow your website's origin.

“Boring” is a compliment here. Add the business's FAQ or basic information, and a visitor can ask a question without taking the scenic route through the navigation.

If the FAQ grows into a library, the same chat can use retrieval over a larger knowledge base. If the application has live data, it can call the application's API. If the application needs to perform an action, the host can explicitly allow that action and handle it itself.

The chat can grow up. It does not have to arrive wearing enterprise architecture on day one.

A conversation is not a transaction

The taxi application taught us to be particularly careful about the difference between “the chat said so” and “the system did so.”

A passenger can ask for an excursion, give a date and time, and say how many people are coming. That is a useful draft. It is not a booking. It does not mean the order was submitted, and it definitely does not mean a driver has accepted it.

The assistant can help prepare the details. In our current flow, Taxi owns the booking form, validation, confirmation and actual order status. We chose that boundary; developers could authorize a different flow to submit the order. A driver is assigned because the dispatch system says so—not because a language model has become optimistic.

The same boundary matters in financial support. A chat can help someone find information or navigate a workflow. The application still decides who is signed in, what they are allowed to do, and whether any operation actually happened.

In other words: the assistant may be helpful, but it does not get promoted to database.

Some useful problems were smaller than “build a chat,” but solving them well made the experience much better. A taxi passenger can dictate where they need to go instead of typing an address. The chat finds the place, shows it on an in-chat map, and passes the selected point into Taxi's booking form, where the passenger can review and confirm the order.

Dictation also lets visitors speak instead of type, with the transcript placed in the message box for review before sending. And when a conversation reaches a human operator, messages are translated in both directions. Operators on Telegram or Slack can reply with a voice note; it is transcribed and translated into the guest's language like a typed response.

And sometimes a chat is just a chat

Once the chat and AI were connected to the same useful information, we could reuse that work in more than one place. For almost no additional infrastructure, a business can let visitors ask questions naturally instead of navigating the site—and use its well-structured knowledge as a practical starting point for generative engine optimization (GEO).

There is an important distinction: an embedded chat does not automatically make a site visible to external AI search engines. It does not rewrite the site's pages or robots.txt, and it cannot promise that another AI will crawl or cite the business. We explain what this GEO foundation does—and does not—mean in the public integration guide.

Where the job calls for AI clients to query live data directly, we can expose the relevant API through tools or MCP. We did that for Radioller's live station catalog. It is a specific integration, not a button that turns every chat into a universal MCP server.

Looking a little further ahead, perhaps an AI will pick up our plans over morning coffee—or catch a half-formed thought—and order a taxi without a chat or a website anywhere in sight. That future may be a year or two away. Let's give it a little time.

Until then, explore FodyChat and try the playground.