Blueprint

Ops dashboard frontend

A Vite/React dashboard over the tables you already have — one object view, one grid, four tiles and a trend — deployed and promoted through dev, staging and production.

Custom frontendFor developers · agenciesIllustrative until verified
1
object
1
form
0
workflows
1
grid
0
platform screens
11
named operations

tbd "Open in CodeMonster" arrives when the desktop app ships deep links. Until then: copy the prompt, paste it into your agent.

Jump to the starter prompt Request an invite

What it builds

Two halves. On the platform: a small solution with a targets object and its form, an object view over completed inspections by week, and a paginated grid on top of that view. In a repository: a Vite + React + TypeScript frontend that reads those objects through the documented REST API and renders four tiles and one trend chart.

This is the escape hatch, and the one place the agent writes code. The platform holds the data and the governed reads; the React app is yours to shape. No platform screens here — the count above is honestly zero.

Which credential the browser uses for those reads is the first thing to settle in scoping. Documented public object reads are not the right door for tenant rows, and the authenticated read path for custom frontends is being finalised for launch — ask us for it before you build.

The primitives map

  • Object — one: dsh_targets, a real table for monthly targets.
  • Object view — dsh_weekly_throughput, SQL-backed over completed inspections by week, with WHERE tenant_id = ? injected for you.
  • Form — Target: metric, month, value. Managers keep targets current without touching the frontend.
  • Grid — one: throughput by week, paginated, filterable with the usual operators.
  • Workflows and screens — none. The frontend is the screen.
  • Frontend — a standard Vite/React repository, deployed through the same pipeline and environment chain as everything else.

The build, as an op-log

The frontend is absent from the op-log because it is not built through platform operations. The agent scaffolds the repository and deploys it to develop; you promote from there. Owners and editors promote to staging; only an owner promotes to production or rolls production back.

dev → staging → production

↩ rollback · promote is one-way · production promote and rollback are owner-only · rollback non-destructive

Starter prompt

Read the fsi and crm solutions and tell me which objects hold inspections, findings and deals. Create a solution called Ops Dashboard with the prefix dsh, an object Target (metric, month, value) with its form, and an object view dsh_weekly_throughput over completed inspections by week. Add a paginated grid view over it and confirm with query-grid that the last twelve weeks return rows. Then scaffold a Vite + React + TypeScript frontend that reads the targets and the throughput objects through the documented REST API, renders four tiles and one trend chart, and deploys to develop. Tell me which credential those reads use before you write the fetch layer. Preview the diff before committing.

Point the prompt at the solutions you actually run. The reads come first so the view JOINs real columns, not guessed ones.

Screens (placeholders)

Screenshots pending [PLACEHOLDER: screenshots of the built dashboard — tiles and trend in develop, the same build promoted to production]

Extend it

  • Add a second object view over deals by stage, and a second chart.
  • Add per-environment env vars so develop reads a test tenant and production the real one.
  • Add a workflow on the source solution that snapshots weekly numbers into a table for history.
Invite only · early access

Bring us something you want built.

CodeMonster is invite only while we work directly with early adopters. Request an invite and we will meet, scope what you want to build, and get you productive. You bring the AI subscription you already pay for.

Request an invite See how it works