Anticode Open builder

Chat app builder: a messaging prototype with scripted conversations

A chat app looks simple: a list of conversations, a thread, a box to type in. The hard part is invisible: messages travelling between people's devices in real time. Anticode can build the visible part as a convincing prototype, with scripted conversations and simulated replies, which is useful for testing a design or a niche messaging idea. It can't make two people talk, because its apps run with no network.

Updated · By the Anticode team

How real-time chat actually works

When you send a message in a real chat app, your device sends it to a server, the server stores it and pushes it to the other person's device over a connection that stays open, usually a WebSocket or a push notification service. The server also tracks who's online, who has read what, and delivers missed messages when someone reconnects. Every one of those steps needs a network and a server.

Anticode apps run in a strict sandbox: no fetch, no WebSocket, no connections of any kind. So a chat between two people isn't something that can be switched on later inside the app. It has to be built on a server.

What a prototype is still good for

  • Design. How threads, reactions, replies and attachments look and feel on a phone, before a developer builds them.
  • A niche idea. A messaging app for a specific group (shift workers swapping shifts, a sports team, tenants of one building) where the special features matter more than the messaging itself.
  • Pitching. Showing investors or a client a realistic session with a few conversations.
  • Usability tests. Watching people find the search, start a group or mute a thread.

Screens and behaviour to include

Conversation list
Names, last message preview, time, unread badges, pinned and muted states.
Thread
Bubbles grouped by sender and time, read ticks, replies quoting an earlier message, reactions.
Composer
Text, emoji, a mock attachment button, and a send state.
Simulated replies
When you send a message in a scripted conversation, a typing indicator and a reply from the script after a short pause, so the thread feels alive.
Groups
A group thread with several sample members and the group's settings.
Special features
Whatever makes your idea different: a shift-swap card that can be accepted, a poll, a location-free meeting suggestion.

Everything is labelled "Demo data" where it matters, so testers know the other people are simulated.

Describing it to Anticode

Give the purpose, the people and the scripts: "A messaging app prototype for a five-a-side football league. Conversation list with team chats and direct messages. Threads with reactions, replies and read ticks. A special 'match card' message that players answer In, Out or Maybe, with a live count. Three scripted conversations: the captain organising Thursday's match, a player asking to swap teams, the league admin posting fixtures. When I send a message in a scripted thread, show typing and a scripted reply. Dark theme, phone-first."

Anticode writes it as one app. Messages you type are saved in that browser, so a demo session survives a reload. Then iterate: try the match card as a pinned banner instead, change the tone of the scripts, add a mute option.

Building the real version

A working chat app needs a server that keeps connections open and stores messages, plus accounts, push notifications, media storage, blocking and reporting, and careful handling of personal data. Options, from least to most work:

  1. Use an existing messaging tool if the special feature isn't essential. Many groups do fine with what members already have installed.
  2. Build on a hosted real-time or chat service, which provides delivery, presence and history through an SDK, with your own interface on top.
  3. Build from scratch. The Next.js export of the prototype gives a developer a TypeScript project with Postgres, email sign-in and roles as a starting point. Real-time messaging is not part of it; the developer adds it, usually with a hosted service.

Whichever route, your prototype's screens and scripts become the specification.

Limits

  • No messages between devices, ever. Each device has its own copy of the scripts.
  • No notifications, accounts or contact lists.
  • No voice or video calls. The sandbox has no camera or microphone access.
  • No AI replies. Simulated replies are scripted; no model runs in the app.

For a bot conversation rather than people talking, see the chatbot prototype. A wider community idea fits the social media app builder.

Questions people ask

Can a chat app builder like Anticode make two phones talk?

No. Its apps have no network access, so messages can't travel between devices. The prototype simulates the other side.

Can visitors message me from my website instead?

Yes, through a contact form. Messages reach you by email and in the dashboard, and connectors can post them to Slack or Telegram.

How realistic can the simulated replies be?

As realistic as your scripts. Write them in the voice of the people you're imagining, with the typos and short replies real chats have.