Web apps and dashboards: what Briks builds today
Besides websites, New project offers App and Dashboard. This page explains what each builds today, where its data lives and what is not available yet, then walks through three projects: a booking request app, a stock tracker and a café's orders dashboard.
The three kinds
| Kind | How New project describes it | What it builds today |
|---|---|---|
| Website | Pages people visit: a shop, a clinic, a restaurant, a portfolio. | Designed pages with pictures and motion, covered across the Building section from Start a new project. |
| App | Something people sign in to use: a client portal, a booking tool. | A website with working parts: forms that save, records you manage, pages and lists built from those records, and search. |
| Dashboard | Numbers a team keeps an eye on: sales by stage, stock to reorder. | Screens for daily work: navigation, key figures, charts, tables, record details, forms and settings. |
Start an app or a dashboard
Choose the kind
Where: New project
Click New project in the sidebar, choose App or Dashboard, give it a name and click Next.
Say what it keeps
Where: Describe it
Describe who uses it and what it does. Name what it should store, what each record holds and who updates it. For a dashboard, Start from an example offers Sales pipeline and Stock levels as starting points.
Choose the stops
Where: How it is built
An app offers the same switches as a website. For a dashboard the step says “A dashboard builds straight through, with no words to approve and no look or hero to choose.”
Build it
Where: Review and create
Click Build it. The first version takes a few minutes, and you can watch it build.
Check the records
Where: Database
Once it is published, open the Database tab to see each collection and its records.
What an app can do today
An app is planned and built like a website, with the same questions before building, approval stops and look boards. When your description asks for something to be stored, it also gets:
- Its own database. Made for you, in the EU, the first time the build stores something: bookings, products, events, enquiries or posts.
- Forms that save. The standard form keeps each entry under Settings, Forms and emails it to you once the site is in production. A form can instead save each entry as a record, where you can find it, edit it and change its details later. Ask for that in your description.
- Pages built from records. A list page and a page for each record, so every event or product is a real page search engines can find. After records change, the published site catches up within a few minutes.
- Search across what it stores, when you ask for it.
- Accounts and payments, when you ask for them: sign-up and sign-in for its own users, one-time payments and subscriptions through your own processor, and shipping or stock built with your own payment account. See Sign-in and payments.
- A service of yours, with your own key, such as a mailing list, a CRM or a spreadsheet. Ask for it as a change once the site is published: Briks asks for the key first, with a field that saves it straight to Secrets, and the site's own server code calls the service with it. Pages in a visitor's browser never call another address. See Questions before building.
Before a site with this kind of working code is published, Briks reads the code for security slips: keys written into files, saving with no limit, members' records read without anyone signed in, and database queries pieced together from text.
What a dashboard is
A dashboard is built as screens people work in every day, not as a page people scroll. Expect:
- A frame with navigation down the side, as a slim icon rail, or across the top, plus a top bar.
- A header on each screen with its title, a line about it and its main actions.
- Three to five key figures, charts with units and labels, and tables with search, filters, sorting and pages.
- Record details, forms and settings screens where your description needs them.
- On a phone, the side navigation becomes a menu and the figures stack two to a row, then one.
There is no hero, no marketing headline and no scroll animation, and no pictures are made. A dashboard also skips the questions before building and the approval stops: it builds straight from your description.
Where its numbers come from
A dashboard keeps its records in the project's database, a table for each kind of record its screens show. The first version fills them with believable sample records that agree with each other; the products, prices and people your description names become records, and anyone else gets an invented name. Its tables, charts and key figures read those records, every total worked out from the rows, and forms that add or change a record save it. Its sign-in pages work: while it is a preview anyone with its address can open it, and once you publish it to production only signed-in Staff and Admin accounts see its data. Sign up on it with the email you use in the studio to become its Admin.
To shape its records, say in the description what is stored, what each record holds and who updates it. You edit the records in the Database tab, and the screens follow.
Your records in the Database tab
Once a project has a database, its Database tab has five views: Data, Accounts, Orders, Subscriptions and Settings. Owners and Admins see the tab before that too, with Create database.
- Data lists each collection with how many records it holds. Owners, Admins and Editors can open, edit and delete records. “Changes reach the published site within a few minutes.”
- Accounts lists the people who made an account on the site, where you set each one's role to Member, Staff or Admin. Orders lists what the site sold through your own payment processor, and Subscriptions the members paying for plans that renew. Accounts and Orders say No accounts yet or No orders yet until the first one arrives.
- Settings holds downloads (up to 50,000 records a collection, as a spreadsheet or as JSON), restore points and the nightly copy. Downloads and nightly copies come with a paid plan.
Database covers the records in full, and Backups covers copies and restoring.
Scheduled tasks and webhooks
Two sections in the project's Settings, in the Developer group, let an app act on a timetable or tell other software what happened.
- Scheduled tasks call an address on a timetable you choose, such as Every day at 09:00 or Mondays at 09:00: either one of your app's own addresses starting with
/api/, or another one. Your app needs that address first, so ask for it as a change. See Scheduled tasks. - Webhooks send a message to another address when something happens: Published, Form received or Record changed. See Webhooks.
| Plan | Scheduled tasks a project | Webhooks a project |
|---|---|---|
| Free | 1 | 1 |
| Starter | 5 | 5 |
| Pro | 10 | 10 |
| Studio | 25 | 25 |
| Agency | 50 | 50 |
What is not available yet
- Plans that renew through PayPal, Mollie, Razorpay, Creem or Dodo Payments: these take one-time payments only for now. Subscriptions go through Stripe, Paddle, Polar or Lemon Squeezy.
- Exporting form entries from Forms. Records in the database can be downloaded on a paid plan.
- Email from your own domain. Site email sends from your project's own address at emails.briks.live.
- A public API, an MCP server or a command line for Briks itself.
Other software can still be reached in three ways: webhooks send events out, scheduled tasks call an address on a timetable, and a change can connect a service that takes your own key, as described above.
Three worked examples
Paws & Suds is a dog grooming salon in Bristol. A booking request app: owners choose a service (full groom £55, bath and tidy £38, nail clip £12), a preferred day and morning or afternoon, and give their dog's name, breed and size and their phone number. We ring back to confirm. Keep every request as a record with a status of new, confirmed or declined. A home page with our services, prices and opening hours.
A home page with the services and prices, and a request form. Each request is saved as a record in a booking requests collection, shown in the Database tab with its count. Whoever takes the calls opens each new request, rings the owner and changes its status. It does not check a calendar for free slots. A deposit through your own processor, or accounts so owners can sign in and see their bookings, would need asking for in the description.
Fern & Stone is a garden centre with shops in Harrogate and Ripon. An internal stock dashboard: every product with its category, stock at each shop, reorder level, supplier and last delivery date. Flag anything below its reorder level. Keep the products as records our manager updates every Friday, and read every figure from them.
Navigation for Overview, Products and Suppliers. The overview leads with key figures such as lines below their reorder level, a table of what to reorder and a chart by category. The products are records in the Database tab; on Friday the manager edits the counts there, and the dashboard catches up within a few minutes. Once it is published to production, only signed-in Staff and Admin accounts see its figures: the manager signs up on it, and the owner gives that account the Staff role under Accounts.
Little Kiln is a café in Hebden Bridge. An orders dashboard: orders and takings today and this week, takings by day for the last 30 days, the five best sellers, and a table of today's orders with the time, items, total and whether it was eat in or takeaway.
The screens arrive as described, reading the orders from the project's database, which the first version fills with believable sample orders. It cannot read the till or the card reader. To track real takings, replace the sample orders in the Database tab, or ask for a daily takings collection and enter each day's figure there.
Which kind should I pick for a client portal?
App. Ask for client accounts in the description and say what each client may see. Clients sign up with email and password, and you set roles under Database, Accounts. See Sign-in and payments.
Can a website store things too?
Yes. Ask in a change for what it should keep, such as events or products, and the database is made the first time the build stores something.
Does a dashboard update by itself?
Only from records in its own database. It does not read your other software unless a change connects a service with your own key. When you change a record, the published dashboard catches up within a few minutes.