Unequal tiles encode priority: a bigger tile is a more important metric, so the hierarchy reads before you have read a single label.
What we build
Web App
A working tool — sign-in, data, dashboard — not just pages.
A website tells people about your business; a web app RUNS part of it. Bookings, orders, customers, staff — screens with real state behind them.
Describe the tool and the builder generates a clickable prototype of the screen, with sample data, and designs the data model behind it. Your download contains the real project: sign-in, a Postgres database with row-level security so each account sees only its own rows, pages to add and list your data, and payment routes you connect yourself. Editing and deleting records are not generated yet, and the project has its own plain styling. Putting it online is yours to do: a free Supabase account and about fifteen minutes with the setup guide, or hand the folder to any developer.
Optional — a logo, a photo of your place, or a screenshot of a site you like. Drag them here. Nothing is stored after the build.
What a build includes
- A clickable prototype: sidebar, stat cards, tables and modals with sample data
- The real project in your download: Supabase auth, Postgres with RLS, payment routes you connect yourself
- A setup guide that assumes you have never used a terminal — or give the folder to a developer
- Source code you own — no lock-in, nothing stops working if you stop paying us
- Refine the prototype by chatting: add a column, a filter, a new screen
How to use it
- Name the job the tool does: 'track my workshop's orders', 'let staff manage bookings'
- List the columns and actions you need — who uses it and what they must see
- Build, then refine the screens in plain English
- Design the data model when the build finishes — that is what turns the screen into an app
- Want it live without setting anything up yourself? That is a quoted service: /business-apps
What this type has to get right
- The most important number sits top-left — eye-tracking shows an F-shaped scan: across the top, then down the left edge
- One number per tile, with its unit and change inline; every chart shares one colour scale
- Cards reflow at smaller widths instead of shrinking, so density survives the phone
Where it usually goes wrong: Every tile the same size and weight — nothing is ranked, so the user reads all of it to find one thing.
Designs that suit a web app
Every one of these is a real design language, and every card below is that language's own page shrunk down — not a picture of it. Open one to see it full size, or name it in your prompt and the build comes out in it.
Dark chrome recedes and lets charts and code carry the colour — the reason editors and analytics tools have used it for decades.
A strict grid and one type family in a few weights are what make forty numbers comparable instead of decorative.
On a dashboard every non-data pixel competes with the data. Restraint here is function, not fashion.
Right for a floating command palette or overlay — but never the data layer itself, where translucency destroys contrast.