AI coding agents can build in-product chat. Should they?

Yes.

That is exactly why this page exists.

A modern coding agent can generate a conversation list, a composer, unread badges, and a couple of API routes.

That makes "add chat" feel like a commodity feature.

It is a commodity feature to start.

The maintenance trap

The problem with agent-built infrastructure is not that it fails to exist.

It is that it now belongs to you.

For in-product chat, ownership tends to expand along predictable lines:

1. just a list and a composer
2. who is the author, really?
3. one 1:1 per pair
4. groups, add, remove, leave
5. attachments and a cost cap
6. do we need a public URL?
7. where is the text stored?
8. how do we moderate spam?
9. can Slack hear about new messages without getting the body?

This is not an unusual story. It is the default story.

Bootstrapware's role

Chat is not anti-agent. It is a product built for an agent-native development world.

The premise is:

• agents are good at building and wiring
• small SaaS teams are still the ones who inherit maintenance
• buying narrow production software is often a better use of time than owning another generated subsystem

So the correct pairing is often:

AI agent
  → integrates @bootstrapware/chat
  → your team ships faster
  → you do not own a chat platform as a product

Prefer embed-only. Assert user.id from your session. Choose BYO ($9.99) or Hosted ($19.99). Never send message bodies through MCP. MCP configures apps only.

Hand the agent this brief or the AGENTS.md rules.

When you should still build

If messaging is the product, buy Stream or build. See vs Stream and build vs buy.

Related: Cursor · Prompt template · Build vs buy · AGENTS.md