---
title: "Web apps and dashboards: what Briks builds today | Briks"
url: https://briks.dev/docs/web-apps-and-dashboards
description: "What the App and Dashboard kinds build, where their records live, what is not available yet, with worked examples for bookings, stock and a café's orders."
last_updated: 2026-10-08
---

# 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.

9 minute read Checked against the studio on 8 October 2026

## 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](https://briks.dev/docs/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. |

Sign-in and payments

Ask for accounts and your app gets sign-up and sign-in for its own users with email and password, with Google and seven more providers you can switch on with your own keys. It can take one-time payments and subscriptions through your own processor too. Both are set up in the project's **Settings**: see [Sign-in and payments](https://briks.dev/docs/sign-in-and-payments). Shipping is built into the app when you ask, with your own payment account and its keys saved to [Secrets](https://briks.dev/docs/secrets).

## Start an app or a dashboard

1. Choose the kind

   Where: New project

   Click **New project** in the sidebar, choose **App** or **Dashboard**, give it a name and click **Next**.

2. 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.

3. 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.”

4. Build it

   Where: Review and create

   Click **Build it**. The first version takes a few minutes, and you can [watch it build](https://briks.dev/docs/watching-a-build).

5. 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](https://briks.dev/docs/questions-before-building), [approval stops](https://briks.dev/docs/approval-steps) and [look boards](https://briks.dev/docs/pick-a-look). 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](https://briks.dev/docs/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](https://briks.dev/docs/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](https://briks.dev/docs/questions-before-building#keys).

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**.

Where

1. Projects
2. Your project
3. Database
4. Data

- **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](https://briks.dev/docs/database) covers the records in full, and [Backups](https://briks.dev/docs/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](https://briks.dev/docs/crons).
- **Webhooks** send a message to another address when something happens: **Published**, **Form received** or **Record changed**. See [Webhooks](https://briks.dev/docs/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](https://briks.dev/docs/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

App Booking requests for a dog groomer

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

Dashboard Stock tracker for a garden centre

> 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**.

Dashboard Orders dashboard for a café

> 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](https://briks.dev/docs/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.

## Read next

- [Data and automation **Database** Find what your site stores, edit and add records by hand, and download collections as JSON or CSV, with who can do what and the limits that apply.](https://briks.dev/docs/database)
- [Your site's features **Forms** Add a form to your Briks site, test it in preview, find every entry in the studio, get each one by email in production and pass them on with a webhook.](https://briks.dev/docs/forms)
- [Data and automation **Scheduled tasks** Run a scheduled task on your site at set times: a morning summary, a weekly tidy up. Write a schedule, read each run, fix one that fails, and see plan limits.](https://briks.dev/docs/crons)
- [Data and automation **Webhooks** Send a signed message to another tool when your site is published, a form is sent or a record changes. Payloads, signatures, retries and deliveries explained.](https://briks.dev/docs/webhooks)

Still stuck?

Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.