Registration with tiers and a cap
Ticket types with a price, a tier by date and a limited quantity. When they run out, they run out in the database rather than in someone's judgement.
Registration, a QR-code ticket, check-in at the door, the programme and announcements for people already there.
Every event turns into two spreadsheets and a queue. The spreadsheet of registrations, the spreadsheet of who paid, and the queue at the entrance because somebody is looking for a name on a printed list. All three disappear when registration, payment and ticket are the same record: the QR code is scanned at the door, the scan marks attendance, and the list of who is present exists while the event is happening rather than afterwards.
People reach this page looking for
What gets built
Not a feature list. These are the apps people actually describe, and what the platform hands back when they do.
Ticket types with a price, a tier by date and a limited quantity. When they run out, they run out in the database rather than in someone's judgement.
Issued on payment, sent by email and opened on a phone. Each one is unique and can only be scanned once.
A scanning screen on the team's phone: scan the code, confirm the name, mark attendance. A second scan of the same code raises a flag.
Talks with times and rooms, favourites for each attendee, and push for a last-minute change, which is when an announcement actually matters.
Included
Database, login, payments and publishing are part of the platform, not a list of services you go and wire up afterwards.
Every screen reads and writes models you can open, query and export. The data is a database of yours from the first minute, not a spreadsheet the app pretends to read.
Email, magic link and Google sign-in, with roles and per-record ownership enforced by Postgres itself. A badly written screen cannot become a leak, because the database answers empty.
Stripe, Pagar.me and Mercado Pago connect once. Card, Pix, boleto and subscriptions, with the card fields rendered by a hosted vault your app never touches.
One project published three ways: your own domain, an icon on the phone straight from the browser, and a signed binary submitted under your own store account.
Titles, metadata, sitemap, structured data and social images are generated with the app. Pages get found instead of only being linked.
Real React, edited line by line or by clicking the element on screen, exported as a ZIP or pushed to your GitHub. No lock-in you have to negotiate your way out of.
How it works
Three steps, and the second one is the one people do not believe until they watch it.
Say what the app does and what it has to remember. No diagram, no schema, no naming a single framework.
Screens, data models, login and payments appear while you read. Anything you do not like, you say so and it changes.
Live on your domain in seconds, with version history behind you. Tuesday's conversation is Tuesday's release.
Start here
This is a complete first message, not a slogan. Paste it, change the nouns to yours, and you have an app to react to instead of a blank page.
Build an app for a two-day event. Ticket types with a price, a tier by date and a limited quantity, paid by card; registration issues a ticket with a unique QR code, sent by email and opened on a phone; the team has a scanning screen that confirms the name, marks attendance and warns when a code has already been used; a programme with talks, times, rooms and speakers, and attendees marking the ones they want to attend; push announcements to everyone or only to people who marked a given talk; a public event page with the programme and registration, written to be found by search engines; and an admin area only I can see, with registrations by ticket type, revenue per tier, attendance per day and the most-saved talks.
Ready to start from
A template is a working app with data already in it. Open one, make it yours, publish it under your own account.
Class booking for a studio with a hard capacity: credits, a waiting list that moves itself, and a door roster that records who came.
A salon diary where every appointment reserves the turnaround, so a gap on the board is time that can really be sold — and an assistant that says which gaps are worth a call.
Questions
Not reliably. The scan confirms the ticket against the database, so it needs a connection. In a venue with poor signal, what usually works is a dedicated 4G router for the door team, and it is worth planning that in advance.
Keep looking
Most apps end up sitting between two categories. Nothing stops you from asking for both in the same paragraph.
Requests, assigned drivers, pricing per route and tracking, with separate sign-up for passengers and drivers.
Availability per professional, services with different durations, a deposit taken at booking and a reminder the day before.
Classes with limited places, check-in, a training plan per member and a membership billed as a subscription.
Availability per practitioner and per room, patient records, insurance and private pricing, confirmations and reminders.
Grooming appointments, a record per animal, prepaid packages and a reminder for anyone who has not been back.
Job cards, quotes the customer approves, a history per vehicle and a bay schedule.
Availability per professional, confirmation, reminders and check-in — the classic agenda, without the spreadsheet.
Menu, cart, delivery fee by area, payment and order tracking, in your own app and with no marketplace commission.
A QR-code menu, ordering at the table, reservations and a loyalty scheme, without a PDF pretending to be a menu.
Free to start, no credit card. You only pay when you want to publish under your own brand, and you take the code with you if you ever want to.