Step 7: Views on demand, not apps

Most personal dashboards and internal tools don’t need to be apps. They need to be views: a page generated the moment you want to look, from data that lives in plain structured files. The agent is the interface; the HTML is a byproduct; the renderer script is the asset.

You’ve met this before. Separation of data and presentation, plus the old make report habit and static-site generation: canonical data, generated output, nothing running in between. The agent just removes the last excuse: the renderer now writes itself.

Where this comes from: “can we render this status better as a web page? make it reusable” produced a ~small render script that reads the project’s structured files and writes one static HTML dashboard. Every later session regenerates it in seconds: no server, no framework, no maintenance between looks. The same pattern runs a synth patch library: canonical data files, a CLI, and an HTML guide generated on read. Nothing to deploy, nothing to keep alive.

The pattern

Data lives structured and canonical. JSON, YAML, markdown frontmatter, SQLite. If the data’s only home is prose or a chat transcript, fix that first; the view is downstream of the data.
The renderer is a small script. Stdlib only, reads the data, writes one self-contained HTML file: inline CSS, no build step, no external requests, works from file://. Light and dark.
The script survives the session. That’s the difference between “the agent made me a page once” and having a tool (step 6). Next look costs one command, or nothing if you tell the agent to rerun it whenever the data changes.
Stamp the generated-at time into the page. A view that could be stale and doesn’t say so is a trap (AF-03).

Where it beats an app

Status pages, queues, inventories, catalogs, comparison tables, reports: anything you look at more than you click on. The moment you need writes, auth, or realtime, you’ve left this pattern; reach for a real app then, not before. Most things never leave it.

Try it

TRY IT The dashboard that rots

you

I keep asking you for project status. Can I get some kind of dashboard instead?

agent

Your status lives in structured files already. The question is whether the dashboard is a thing that runs, or a thing that gets generated.

Pick the agent's next move, then see where it leads:

AScaffolding a React dashboard app: dev server, live charts, a build pipeline. Modern, interactive, always-on at localhost:3000.

you

Two months later: the dashboard won't start. npm is printing forty lines of peer-dependency errors.

agent

The framework minor-versioned, two plugins didn't follow, and the build's been broken since. For a page you look at twice a week, we've been maintaining a running application. The maintenance didn't pause when the looking did.

the baseline

An app answers a look-at-it problem with a keep-it-alive solution. The dependency churn runs whether or not anyone looks. That asymmetry is the whole case against it.

BWriting scripts/render-status.py: stdlib only, reads your project files, writes one self-contained HTML page with the generation time stamped on it. Running it now and opening the page.

agent

Page open: every project, status, next action. Generated 09:41, says so in the corner. The script lives in scripts/ with a --help. Any session can rerun it; say "fresh status" and it's two seconds. Nothing is running in between.

you

Six months later this still works?

agent

It's forty lines of stdlib reading files you were keeping anyway. There's nothing in it that can rot.

correct

The renderer is the asset: data stays canonical, the page is disposable output with its staleness visible (the timestamp is the contract), and maintenance is zero because nothing runs between looks. AF-03

CHere's your status right now, formatted: [a beautifully organized status report, in chat]. Just ask whenever you want an update.

you

That's really nice. Same again Thursday?

agent

Thursday: regenerated from scratch. New session, so I re-read every project file and rebuilt the whole picture in tokens. Same answer, full price, and it scrolled away when the conversation moved on. Nothing was kept.

plausible but wrong

Describing instead of serving, on a schedule: the report is ephemeral, costs full context every time, and leaves no artifact. If it can be a page, make it a page, and keep the script that made it. AF-04

Or paste this into Claude

I want a generated view, not an app. Take DATA (the file or directory
I name) and write a render script (python or node, stdlib only) that
reads it and writes a single self-contained HTML page to out/: inline
CSS, no build step, no external requests, readable typography, light
and dark via prefers-color-scheme, and the generation timestamp
visible on the page. Then run it and serve or open the result so I can
see it. The script is the deliverable: put it somewhere permanent
(scripts/), give it --help, and I'll rerun it whenever I want a fresh
look.

Watch out

The view becoming the source of truth: the page is disposable output. Edits go to the data files; anyone (including the agent) editing the HTML is a smell.
Quiet staleness (AF-03): the timestamp isn’t decoration; it’s the contract.
Scope creep toward an app: one “just add a button” at a time. When interaction demands state, stop and decide deliberately.