Dashboards and custom frontends

The problem: four numbers, the company colors, the TV by the door

The composite version, heard often enough to be a pattern: the app works, the data is right, but the ops director wants one screen with four numbers and a chart, in the company colors, on the TV by the door — and the platform’s grids are not that screen.

Sometimes the renderer is the wrong shape for the job. A public dashboard. A client-facing widget. A landing page that reads live numbers. You want to write React and be done, without giving up the backend, the environments or the audit trail.

What gets built: React over object views, same chain

This is the escape hatch — the one place on the platform where your agent writes ordinary code. Custom frontends are live and shipping: a Vite + React + TypeScript scaffold — or any framework that builds to static output — that reads the platform API and deploys through the same environment chain as everything else.

• Data stays on the platform. Object views shape it for the screen — joins, computed columns, the tenant filter injected on every query. The agent tests them with test-query and query-grid before a line of React exists.
• The frontend is an ordinary repository. Normal package.json, your editor, your charting library. It reads the platform API for public object reads; it does not get a second backend.
• Per-environment variables — the API base for develop, staging and production — are applied at build time, so promotion rebuilds for the target rather than copying bytes.
• Static builds only. The pipeline ships a dist/ with an index.html. No servers, no server-side rendering, no backend hosting for the frontend. Server-side functions are on the roadmap, not in this list.

Starter prompt

I have a platform solution called Ops Desk with objects ops_ticket and ops_team. Create an object view kpi_daily that joins tickets to teams with computed columns for opened, closed and open-at-end-of-day per team per day, and a view backlog_by_team with the current open count and oldest ticket age per team. Test both with a query for the last 30 days.
Then scaffold a Vite + React + TypeScript dashboard that reads those two views from the platform API: a headline row (open now, opened today, closed today, oldest ticket), a 30-day line chart per team, and a backlog table sorted by oldest ticket. Read the API base URL from VITE_API_BASE.
Deploy it to develop so I can look at it. Do not promote to staging yet.

Ship it: develop, staging, production — owner-gated

Custom frontends move develop → staging → production, strictly one way: a deploy lands in develop, and every tier after that is reached by promotion. Editors take the build to staging. Production, and any rollback out of it, is owner-only.

↩ rollback · owner / editor / viewer · production is owner-only

Rollback is non-destructive: a new deployment pointing at the previous succeeded version, with the audit trail intact. Every deploy, promotion and rollback is a row in an append-only deployment log — version, environment, who, when, status, URL. Every environment gets an HTTPS URL on our domain; custom domains are not offered yet.

Integrations used

The platform API for reads. Per-environment variable bundles for configuration. Whatever you import: the pipeline cares about the output directory, not the framework. Analytics and third-party widgets go in the frontend the way they would anywhere.

Related

• Custom frontends — the scaffold, the seven-phase pipeline, the honest limits.
• Blueprint: Ops dashboard frontend — the copyable object views and prompt.
• Closed in 24 Hours: CRM-lite for 35 consultants in 22 hours — an illustrative agency build with a client-facing view.
• Do I own my apps? — a custom frontend is a repository you hold; the data behind it stays yours through the documented API.