A booking page that takes a deposit and confirms automatically.
The slot is held, the payment arrives, the client gets the confirmation. Your team sees the day fill up.
Web Publish
It builds the app. And puts it online.
From a one-page price list to a full application with its own server and database. Describe it in the chat: your employee builds it, deploys it on your domain and hands you the address. No developer, no hosting to set up, no ticket.
New in v2.8 · Full-stack apps
Not a page. A working application.
Describe what you need in the chat. Your employee builds the interface, the server and the database, deploys it and hands you the address. Visitors can fill it in, pay through it and watch it update live. It keeps running after the conversation ends.
What this used to take
- A developer
- A hosting account
- A database to set up
- A domain and a certificate
- A deployment
- A few weeks
Now: one conversation.
You, in the chat“We rent three meeting rooms. I want a booking page where clients pick a slot and pay a deposit, and a screen for us that shows today’s bookings as they come in.”
book.yourcompany.comLive
The interface
The booking page for clients, the live screen for your team. Works on a phone and a laptop.
The server
Checks the slot is free, records the booking, sends the confirmation. Real code, running around the clock.
Its own database
Every booking kept, searchable and backed up. Nothing lives in a spreadsheet someone forgets to save.
Events come inThe deposit is paid: the payment service tells the app, the booking is confirmed.
Screens update liveA new booking appears on your team’s screen without anyone refreshing.
What people build with it
One sentence in the chat. An app your business runs on.
These are the kind of requests it turns into a running application. Each one keeps its data, reacts to what happens and lives on your address.
A page where each client follows where their order stands.
When the delivery status changes, the page changes with it. No more “any news on my order?” emails.
A quote calculator on our site that saves every request.
Visitors get a price in seconds. You get every request stored, with the details, ready to call back.
Registrations for our event, closed when we hit 120.
Sign-ups are counted as they come in. At 120, the form closes by itself and opens a waiting list.
A stock register the whole team updates from their phone.
One number, the same for everyone, updated the second someone takes a box off the shelf.
A form that searches our product sheets and answers.
Hundreds of sheets stored in the app, searched in full text, the right one returned in a second.
Under the hood
Built to run for real, not to demo.
For the person in your company who will ask how it works.
A real server runtime
Each app runs on Node.js: modules, calls to other services, timers. Not a static page pretending to be an app.
One SQLite database per app
Parameterised queries, transactions, triggers and full-text search. Isolated from every other app.
Safe database operations
Consistent snapshots, integrity checks and atomic replacement, so a restore never leaves a half-written database live.
Webhooks that can be verified
The raw request body is preserved, so signatures from payment and delivery services can be checked.
Real-time built in
Native WebSockets broadcast across workers, and real-time channels with short-lived tokens and messages encrypted at rest.
Your domain, with its certificate
Type the domain, add the records, verify. The certificate is issued and renewed, and a failed change rolls back.
How it works
You ask in the chat. It is online.
There is no export, no upload and no hosting step in between. The employee writes the page inside its own working folder, and that folder is served to the web. What it saves is what visitors see.
1. You describe what you need
In the same conversation you already use for calls and email. “A one page guide for new patients, with our address, the opening hours and how to find the entrance.”
No brief, no wireframe, no ticket. If you have a logo or a colour, say so in the same sentence.
2. It writes and publishes
You watch the page take shape in the thread, the same way you watch any other task. When it is done, the employee publishes it and the address becomes live immediately.
Want a change? Ask in the same thread. The page updates at the same address, so anything you already sent out keeps working.
3. You get a real address
A public link you can text to a patient, print on a flyer, or point your existing website to. It opens on a phone the same way it opens on a laptop.
The address lives on your own domain, because a published page is served by your workspace and carries its name.
Every page in one place
The workspace keeps the register
Whatever your team publishes shows up under Workspace › Websites. One line per page, so nothing you put online is ever forgotten in someone’s folder.
- The address, ready to share. Copy it in one click, or open the page and check it looks right before you send it to anyone.
- The employee who made it. Every line is signed, so six months later you still know who to ask for a correction instead of starting over.
- The day it went up. Useful when a price list has been sitting online since March and nobody remembered.
- Rename, replace or take down. A page you no longer want disappears from the same screen, and its address stops answering.
- Pages and applications, side by side. A price list and a booking app with its own database sit in the same register and are managed the same way.
A page it produced
This is not a mockup. An employee wrote it.
A dental practice asked for a page that would get people to book again. No agency, no template to fill in, no back and forth over a week. It was written in the chat, published from the workspace, and it has been answering ever since.
Give it something to build
Hire an employee, describe the app, and send the address to a client the same afternoon.
Start free trial