Help Centerchevron_rightWebsiteschevron_rightBuild and editchevron_rightHow to build a web app (dashboards, trackers, portals)
auto_awesome

How to build a web app (dashboards, trackers, portals)

Websites / Build and editschedule6 min readmenu_bookArticle 7 of 10 in Build and edit
open_in_newOpen Websites in Genayaarrow_outward

A web app renders inside Genaya's own app shell instead of a marketing page: a left sidebar with the app's name and one entry per screen, a slim top bar with the page title, a search box and a New <record> button, and an account menu for sign in and sign out. You describe the idea on the Websites home or in any chat; the planner works in app mode: it designs the tables from your words (a to-do gets Tasks with a title, a status, a due date, notes and a done flag), creates them before it writes a screen, then writes the screens - a Dashboard first, then one screen per table plus an All <records> view - and the legal pages. There is no hero, no marketing sections and no stock photos on an app build. Nothing about the app comes from your organization's records: the brief is the whole spec (see "Build from your idea, not from your business").

  1. 1
    Describe the app

    On Marketing > Websites, or in any Genaya AI chat: "build me a todo dashboard", "an inventory tracker with quantity and reorder point", "a CRM for my leads with stage and next follow-up", "a booking system for the crew", "an admin panel for the team". A brief that names an app, a dashboard, a tracker, a to-do, a portal, a CRM, an inventory, a booking system, an admin panel, an internal tool or users is an app; Genaya never asks what your business does or who the visitors are - the words are the brief.

  2. 2
    Watch it build

    The plan block adds "Creating your app's tables" after "Choosing a look", then "Designing your dashboard" and "Building the All <records> screen". Each table appears on Dashboard > Data the moment it exists, with its visibility set to Visitors; the screens land one by one inside the app shell - the Dashboard board or table first, then one screen per table.

  3. 3
    Try it in the preview

    The preview never needs to sign in: the account menu reads "Preview visitor", and a screen with no rows yet shows six sample rows marked "Sample data" so you can see the shape before anyone signs up. Edit any screen like any other section: its view (board, table, list or cards), which field groups the board, which field marks a row done, whether visitors may delete their own rows, the stat tiles, quick add and the search box.

  4. 4
    Publish and sign in

    Press Publish. On the live app a visitor who reaches a gated screen sees a sign-in card in the middle of the frame: they type their email, get a six-digit code (it expires in 10 minutes; three sends per 10 minutes; five wrong tries end the code), type it and are signed in on that site for 90 days. Once in, New <record> in the top bar opens a form to add a row, they see it in the Dashboard or the screen's list at once, move a card between board columns, mark it done, and edit or delete a row from its own menu. Sign out in the account menu ends the session.

The app shell
A left sidebar (the app's name, Home first, then one entry per screen with an icon), a slim top bar (the screen title, a search box, New <record>, the account menu) and the screen itself on a plain surface - no hero, no marketing bands. An app built before this shell shipped opens in it automatically the next time it is opened; nothing has to be rebuilt.
The Dashboard screen
The first screen, always: a board grouped by status with a count per column (or a table with sortable columns), a stat strip (total, a tile per group, percent done), quick add and a search box - each one optional and on by default. Every other table gets its own screen plus an All <records> view.
Sign in
By emailed code only - no password, ever. The sign-in card is part of the app shell itself, not a section you place - it appears the moment a signed-out visitor reaches a gated screen. The code email goes out from Genaya with the site's name as the sender name and counts as one email on your plan's email allowance. A visitor of one site is never signed in on another, even two sites of the same organization.
New <record>
The top bar's New <record> button (and a row's Edit) opens a form with one input per field of the table (text, long text, number, date, yes or no, a dropdown, email, phone, link); required fields are checked before the row lands. Signed out, it opens the sign-in card first.
Records
A table's rows as a board (columns from a dropdown field), a table, a list or cards. Scope "mine" shows each visitor their own rows only, with Edit, Mark done and Delete on a row's own menu when the screen allows; scope "everyone" shows every row to every visitor on a Public table.
Visibility
Every custom table is Private (your team only), Visitors (signed-in visitors add rows and see their own) or Public (everyone sees every row; signed-in visitors add their own). An app table starts as Visitors; change it on Dashboard > Data next to the table's name. Leads and Bookings stay private.
The Visitors card
Dashboard > Data lists every account that signed in - email, name, joined, last seen, how many records, Active or Blocked - for members with the Websites data permission; blocking or unblocking also needs the edit permission. Block signs the person out everywhere at once and refuses new sign-ins; Unblock lets a fresh code sign them in again. Their rows stay.
Accounts per site
2,500 on Pro, 10,000 on Business, 50,000 on Enterprise. The trial and Individual build and preview an app but open no accounts: publishing an app with sign-in is on the Pro plan and above. Past the cap a new visitor sees "This site is not taking new accounts right now"; existing accounts keep signing in.
Records per account
100 on the trial, 500 on Individual, 2,000 on Pro, 5,000 on Business, 10,000 on Enterprise - across the whole site, so one account can never fill the site's record cap for everyone. The site's own records cap (1,000 / 20,000 / 100,000 / 500,000 / 500,000) counts app rows too; form and booking submissions are never refused.
Sign-in codes per day
5,000 on Pro, 20,000 on Business, 50,000 on Enterprise per site. Every code is one email on your plan's email allowance (the usual overage past it), so this is also the most a site can spend on sign-ins in a day. Past the cap the page still says a code was sent and nothing goes out.
Genaya AI
"How many people signed up on my task app?" is answered from the site's visitor count. Blocking and unblocking an account is your call on the page - the assistant never does it.
infoAcross industries: a clinic's intake tracker where each patient sees their own submissions, an advisory firm's client portal for document requests, an agency's feedback board where every visitor sees every card (a Public table), a builder's job tracker with stages, an inventory dashboard for a shop, a crew's to-do board with columns To do, Doing, Done.
warningA visitor account is not a Genaya client or a Client Portal login: it is an identity on that one site, on the site's own database. Nothing a visitor types reaches your leads, appointments or clients unless the page also carries a lead form or a booking section.

Frequently asked

Was this article helpful?