Use cases

Event app

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

  • event management app
  • app for event registration and tickets
  • build an event app with tickets
  • QR code check-in app

What gets built

Four things you could have working this week

Not a feature list. These are the apps people actually describe, and what the platform hands back when they do.

01

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.

02

A ticket with a QR code

Issued on payment, sent by email and opened on a phone. Each one is unique and can only be scanned once.

03

Check-in at the door

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.

04

Programme and live announcements

Talks with times and rooms, favourites for each attendee, and push for a last-minute change, which is when an announcement actually matters.

Included

The parts nobody wants to build twice

Database, login, payments and publishing are part of the platform, not a list of services you go and wire up afterwards.

A real database, not a form dump

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.

Login for your own users

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.

Payments that land in your account

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.

Web, installable, and in the stores

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.

Found in search, and by the models

Titles, metadata, sitemap, structured data and social images are generated with the app. Pages get found instead of only being linked.

React code you can take with you

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

From a paragraph to a published app

Three steps, and the second one is the one people do not believe until they watch it.

Describe it in plain language

Say what the app does and what it has to remember. No diagram, no schema, no naming a single framework.

Watch it get built

Screens, data models, login and payments appear while you read. Anything you do not like, you say so and it changes.

Publish, then keep changing it

Live on your domain in seconds, with version history behind you. Tuesday's conversation is Tuesday's release.

Start here

A prompt you can paste right now

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

Templates in this category

A template is a working app with data already in it. Open one, make it yours, publish it under your own account.

Tessera

Booking

Class booking for a studio with a hard capacity: credits, a waiting list that moves itself, and a door roster that records who came.

15 screens

Serenity

Booking

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.

16 screens

Questions

Frequently asked 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.

Describe it. See it running. Publish it to the store.

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.

Build this app freeUse cases