What we are building

The app owner may always edit its data; editors they invite may too; everyone else only reads. The server enforces it, so hiding a button with a rule is convenience, not protection. The role is available as {{role}}. Still missing: the invite screen in the editor — the editor list is managed through the API only.

A one-off confirmation of an order already reaches the customer — that part is done. This is about something else: writing to everyone who used the app — «closed tomorrow», «new collection». It needs a list of people who opened the app, a screen to write from, and limits: a bot that mass-mails advertising gets blocked by Telegram, and the app stops opening with it. So not a «send to everyone» button, but a list, consent and rate limits.

The pay button opens a link you created yourself. Stars is the first path where the invoice is issued from the app and the order status comes back to it.

Exporting project.json already works; the way back does not, nor does moving a project between accounts. Your work should not be locked inside one login.

A second person on a project: access, roles, and knowing who changed what. A project belongs to exactly one account today.

Undo works within a session. What is missing is a history of published versions and a way back to the previous one — for the day something breaks after yesterday’s edit.

Remind about tomorrow's booking, an abandoned cart, a membership about to end. Technically this is the same bot that already connects and already sends confirmations; what is missing is a schedule and a list of people it may write to. Invoicing already works — see card payments.

Asked for in feedback: publish posts from the app into a channel or chat. The nearest prerequisite is storing your own bot token — without it there is nobody to post as. No dates yet.

A submission reaches Telegram, is kept in the editor, and can write a row into the app's table or into a connected Google Sheet. Email is the one road still missing.

Asked in feedback. The two platforms use different identifiers with nothing in common, so the same person arriving from MAX and from Telegram is, to the app, two different people. What can link them is what the person supplies themselves — a phone number; there is simply nothing else that both platforms share and that belongs to the person rather than the messenger. Hence the order: ask for the number first, merge profiles second. Until a number is given the two profiles stay separate — we will not guess that they are the same person.

Columns are resizable, the first column and the row actions stay put, a cell expands in place, and there is a search across every column plus sorting by a column with the previous order restorable. Filters and grouping inside the table come next. Reading somebody else's base already works, though: NocoDB, Teable, Baserow and Airtable connect as an external source.

Templates build a whole app. Between a template and a blank canvas there is a gap: a ready-made “cart”, “booking”, “reviews” block you drop into your own screen.

Partly done, and here is the honest boundary. The help lives inside the editor: 61 articles in ten sections — data and substitutions, actions, visibility conditions, screens and the app shell, styling, publishing, custom domains, payments, plans, and worked examples. It opens from the More menu, with F1, from the command palette, and from the “?” buttons next to the things they explain; Russian and English. What is missing: video lessons, pictures inside articles, and a help section on the site itself — so there is nowhere to read it before signing up.

An Address block: the name of the place, the address, opening hours, a “how to find it” line and your own photo — the entrance, the shopfront, the way through the yard. The button opens the map app on the visitor's phone with a route from wherever they are: Yandex Maps, Google Maps or 2GIS, your choice. The address can come from a table, so every branch or listing gets its own route. There is deliberately no embedded map view: someone else's map inside your app is someone else's code next to your visitors, and the phone's own navigation gives a better route anyway.

Buttons and cards can highlight what was chosen: a pair of properties, “Highlight when” and “equals value”, next to the “Set value” action — that is how you build a choice of master, day, time, seat category or size. What was chosen can be added to the request: the “Submit form” action now has an “Add to the request” field, with the label you will read on the left and the value on the right. Before that only typed-in answers travelled, and a salon received “Haircut, 1500 ₽” with no day and no time, and had to call and ask.

A CV with an application, a lab result, a photo of the damage: a visitor attaches a file right in the form and it reaches the owner as a link. Images, PDF, Word and Excel documents, RTF, plain text, CSV and ZIP up to 10 MB. The space counts against the owner's plan, and a file nothing points at any more is removed in about a month.

Done, all three. **Stars** — one block for both showing and setting: with no field name it displays a rating from your data, with a name it becomes a review form field. Halves are drawn, because 4.5 is an average over reviews and rounding it up reads as “everyone is happy”. **A countdown** to a date from a table: every card on a listing gets its own. **“Add to calendar”** — a real event file the phone puts into its calendar; before, the button opened Google Calendar with no time, because a calendar needs a machine-readable date and the template held a human string. Hence one requirement on your table: store the date for the counter and the calendar in machine form — `2026-08-12T19:00` — and keep the readable “12 August” in a column beside it, for people.

Done. The screen strip now marks a screen that carries a control promising a tap and doing nothing, and the tooltip names them: “Checkout”, “Book”. A promise means a button of any kind or a list row with an arrow; a row without one is a display and does not count. A tappable parent counts too: a “Buy” button inside a card that opens the product behaves exactly as a finger expects. Standalone screens from the gallery still arrive without links to your own screens — we cannot wire those for you — but now you see it straight away instead of hearing it from a visitor.

Done. Options of the “one of a list” and “several of a list” columns are reordered by dragging, and a pill's colour is picked by tapping it — eight colours plus “from the name” when you would rather not choose. Colour from the name stays the thing that works with no setup at all: the same word is coloured the same way in every table. Both column types now draw pills in the cell and in the dropdown — neighbouring columns of the same kind used to look like different things. A hand-picked colour lives in the data editor: inside the published app the filter strip and the cards take their looks from their own properties.

The Video block understands a page address copied straight from the address bar and plays it with the host’s own player: VK Video, Rutube, Dzen, YouTube. A direct link to an mp4 file works as before and keeps its own settings, Loop and Muted. Someone else’s player has neither, and cannot: we have no way to command it, and drawing those switches would promise something nothing would keep.

The format used to belong to the column — one for every place at once — so a listing that wanted “7 August”, “19:00” and “7 August, 19:00” needed three columns. Now picking a date column asks two more things: what to show (the date, the time, or both) and how to show it, as a list of samples. Sorting, filters and visibility rules keep comparing the machine value rather than what is on screen.

The chip filter over a date column lays itself out by day, and now by hour as well: one pill per showtime. No extra column is needed — it is the same column asked a different question. The strip also has a “Past days” setting, keep or drop, with today always kept: what is on today is what people come for.

The table window has search across every column at once (it appears from eight rows) and sorting by column. Dates compare as moments, numbers as numbers, “Hall 10” lands after “Hall 2”, and empty values sink to the bottom either way. Sorting edits the document rather than just the view — visitors see the row order — so the previous order goes into an Undo button.

The actions Edit row, Remove row and Fill the form from a row work on any row, including the ones typed in the editor. Who may do it is decided by the server: the app owner and the data editors they invited; everyone else only reads. An edit to a document row shows up in the data panel marked “Changed”, with the original one click away — the document is rewritten in full on every publish, so the edit lives as an overlay on top of the row.

The “Tabs within a screen” block: tapping writes the choice into a variable, and each tab is an ordinary container with a visibility rule. This is not the bottom tab bar, which navigates between screens. Whichever tab opens first is seeded automatically — otherwise the screen would open empty, with no rule matching anything.

The app follows the messenger’s theme, and the visitor may decide otherwise: a “Switch the app theme” action on any button, plus a ready-made theme switch block. Their choice outranks the messenger and survives a reload. Colours in the styling are set as a pair — light and dark — so chips, players and icons change with the theme instead of staying as they were in light.

Done. The token is entered once in the publish dialog, kept encrypted on our side (AES-256) and never returned to the browser — it cannot be shown, only replaced or removed. Publishing then points your bot's «Open» button at the new address by itself. The same token lets the server verify the Telegram launch signature and send a confirmation to your customer.

Connect your own merchant account — YooKassa or T-Bank — in the Publish dialog: it takes the keys from your provider's dashboard, they are verified immediately and stored encrypted on our side. After that any button can carry the «Take payment» action, and the amount can come from a table binding («{{item.price}}»). The buyer pays on the bank's page and returns to the app; the payment is confirmed by the provider's answer rather than by the return itself — and if the person never comes back, a reconciliation pass still settles it. Both sides learn about it: you in Telegram and on the «Payments» screen, the buyer in a message from your bot. The money goes straight to your account: you are the seller, the receipt is issued by your account under its own settings, refunds are made by you there. We never hold your money and therefore cannot return it.

Done. Enter your domain in the publish dialog and the service shows what to add to DNS: one CNAME record for a subdomain like app.example.com, two records for a bare domain (example.com). The rest happens without you: we check the records against your registrar's own name servers, bypassing caches, issue the certificate, renew it ourselves, and point your bot's «Open» button at the new address. The bot messages you once it is live. The old address keeps working, so links you handed out and printed QR codes lose nothing. Registrar changes do not propagate instantly — usually 15–30 minutes, sometimes hours; you can close the page. In MAX the address has to be changed by hand in the partner cabinet, as MAX offers no method for it. Available on the Pro and Studio plans. The owner opens their app on their own domain as themselves rather than as a visitor: an “Open on your domain” button next to the connected domain issues a one-shot link, and the row-editing buttons are there. A sign-in on someone else’s domain is separate from ours — browsers do not carry one across addresses — so the link works once and lives two minutes.

Done. A published app opens in MAX as well as in Telegram — one build, one address. Signing up and signing in through MAX work on a par with Telegram, and the launch signature is verified with your MAX bot token, so the visitor name in a submission is genuine rather than self-reported. What we cannot do: put the app address into the bot for you. MAX has no API method for it — we checked the whole surface — so the address is pasted by hand, once, in the partner cabinet. A MAX bot also goes through their moderation, up to 48 working hours.

The app's table is filled from yours: an Excel or CSV file, a Google Sheet (by link, or through a service account when the sheet is private), a workbook on Yandex.Disk, or any address answering JSON — NocoDB, Teable, Baserow, Airtable and your own API. Rows refresh on their own, on a schedule and at publish time, rather than being copied once. Edits made inside the app can be written back into a Google Sheet.

No dedicated connector needed: app events go out as a webhook to your address, and an inbound address lets your scenario put a row straight into the app's table. Outgoing are a submitted form, a row added or changed, and a completed payment — POSTed as JSON with a signature, retried if your server does not answer. Set up under the More menu → Automation and webhooks.

Suggested in feedback. A «link» field stores a reference to a row in another table: an event points at a venue instead of repeating its name as text. The difference shows up not on the day you fill it in but on the day the venue moves: the address is fixed once, not in twenty rows. Fields of the linked table can be bound — «Venue → Address» — and they appear in the data picker alongside the row's own. Links expand one level deep: enough for the questions people actually ask, and a ring of references cannot loop.

Suggested in feedback. QR turned out to be an output, not a field type: the table keeps a plain string you can read and check by eye, and the component draws the code from it. The value accepts bindings, so inside a repeater every row gets its own QR. The code is built inside the app, with no third-party service. Alongside it, a «random code» field type: a new row gets its number straight away, with no zero/O or one/I/L, because this code gets read out loud at the door.

Asked in feedback. The app can ask for the number: Telegram shows its own consent dialog, the number lands in the {{user.phone}} binding and reaches the owner as an ordinary submission. Content gating comes from the same place — a «show if the phone is filled in» condition closes off buying a ticket or leaving a review until the number is shared, and the opposite condition hides the invitation once it has been used. Declining is a working outcome: {{user.phone}} stays empty, and the screen must work for those who declined too.

48 component types, a layers panel with drag-and-drop reparenting, undo and redo, a command palette, project styles and fonts.

A real editor on a phone: full-width canvas, properties and layers as a sheet, adding components within thumb reach. Data is reachable from a phone too: tables, variables and sources open in a Data sheet, and the table window shows a row as a card — fields top to bottom rather than a seventeen-column grid, of which a phone screen shows about one and a half values.

A store, food delivery, a coffee shop with pickup, studio booking, a medical centre, a car service, events and tickets, fitness, courses, real estate, travel, jobs, music, fundraising, loyalty, a portfolio — each with its own data and screens. Plus 32 standalone screens to add to a project you have already built. Everything in a template that looks like it works does work: every screen has a way in, every button has an action, and choices — a master, a day, a time, a seat category — are real and travel with the request. A build-time test enforces it, not a pair of eyes.

A form adds a row to a table instead of only sending a submission: the «add a record» action turns an app into an admin panel for its own data — fill the listings from a phone. Records are stored beside the published document, so publishing again does not erase them.

Collections with fields, variables, a repeater with filters and sorting. Data drops into any field from a searchable list, with its current value shown next to it.

Visibility rules and list filters understand is-before and is-after, and {{now}} gives the current moment — with an offset. That builds show-only-what-is-coming and drop-what-starts-within-two-hours. Dates typed as words are not compared: guessing wrong would silently hide somebody event.

16 actions — navigate, save into a variable, popups, clipboard, share, QR scanner, haptics — plus visibility rules on any block.

This page, and the «suggest an idea» form in the editor. Everything sent is read; what is accepted becomes a line here.

A form collects answers, validates them and sends them to you in Telegram; submissions are visible in the editor. Preview shows exactly what will be sent, before publishing.

The app gets an address and opens in Telegram. Drafts are kept on the server, so your work is not locked inside one browser.

Your own images on our storage, HEIC from an iPhone included: a link to somebody else’s site stops working in six months; this does not.

How many people opened the app, which screens they saw, and which events fired.

The «write to us» button is a conversation, not a letterbox: the answer arrives in Telegram and shows up in the editor.

The whole editor in Russian and English.

A selected component now carries a strip with its name and the four things people do constantly: go to the parent, add inside, duplicate, delete. A container is exactly the area its children cover, so clicking one was impossible — there is now an arrow for it, and ⌘⇧+arrows to walk the tree. Components can be wrapped in a container and unwrapped again. Text is edited directly on the canvas by double-clicking. The line shown while dragging marks the place the component will actually land, not the one next to it. The padlock and the eye in the layers panel finally do something: a locked component cannot be moved or deleted, a hidden one is drawn faded in the editor and is absent from the published app.

A piece of a screen you have assembled — a card, a header, a block with a button — can be saved as your own block and placed again from the components panel. Styling can be saved as a named style: give it to several components, change it once, and all of them follow. A component carries one style rather than a stack of classes: lists of classes with an application order are a profession, not a builder. Blocks and styles live in the project, so they travel with publishing and with export.

The properties panel now has a search: type «radius» and only the radius fields remain. It works on a phone too, in the same sheet. The ⌘K palette now searches not only commands and components you can add, but what is already on the screen — type a name and jump to the component, even a hidden or locked one. The edit history (⌘⇧H) lists the steps and takes you back to any of them; until now undo worked blind. ⌘S writes immediately instead of waiting for the autosave.

A header, a card, a block with a button that stand on five screens can now be saved as a component. After that it can be placed as many times as needed and is edited in one place: open «Edit component», change it, and it changes everywhere it stands. Before you edit, the screen states how many copies this will touch — so it is not discovered afterwards. Plain copies are still there: «Save as a block» puts a piece of a screen into the panel and inserts it as an ordinary copy that lives its own life. The difference between the two is the only thing to grasp here, which is why there are two lists with two different names. Any instance can be detached and becomes an ordinary copy.

The bot token used to be typed again on every publish and stored nowhere: the app document is downloaded by every visitor, so a token inside it would be everyone's. Now the token goes to the server, is kept encrypted there (AES-256) against your account, and never comes back to the browser — it cannot be shown, only replaced or removed. Publishing then points your bot's «Open» button at the new address by itself: this used to happen from the browser with your token, and a single typo was enough for the app to publish but not open from the bot.

Somebody leaves an order and immediately gets a confirmation in their chat with your bot: «Booking accepted. The barbershop will contact you». It is sent by your bot, not ours: ours has never written to that person and has no right to. The server now also verifies the Telegram launch signature — until now the visitor name came from the browser, where it is forged by opening the console, which means the name on an order was whatever the visitor wrote about themselves. Orders now carry a verified name. If somebody opened the app from a link without pressing Start in the bot there will be no confirmation — Telegram forbids a bot from writing first — but the order is still accepted and still reaches the owner.