Most of what I make follows one pattern. Find data someone already publishes, pull it on a
schedule, and put it somewhere a person can actually read it. The tools change; the shape
rarely does.
The pattern
Scheduled job, plain file, static page
This is how the NJ Transit dashboard works, and it's the shape I reach for first. There is no
server, no database, and nothing running on my laptop. It costs nothing and it keeps working
when I'm not looking at it.
Find data that's already public
Agencies publish more than people realize, often badly formatted and rarely explained.
The work is usually in the framing, not the acquisition.
public agency files · open APIs · federal datasets
Fetch it on a schedule
A script runs on a timer, downloads what's changed, and normalizes it. It retries when
the source is flaky, and it fails loudly rather than writing bad data quietly.
python · github actions · cron
Commit the result as a file
The output is checked into version control, so the commit history doubles as a record
of when the underlying numbers actually moved.
json · git
Let a page read that file
One HTML file, no build step, no framework. The page fetches the data and draws it.
Fast to load, nothing to maintain.
html · css · javascript · svg
Publish it somewhere free
Static hosting on a domain I own. Every push redeploys.
github pages · custom dns
When the shape changes
Three other patterns I use
When the data is mine and lives in Google's worldPersonal tools where I'm the only user. A phone shortcut writes to an endpoint, a
script categorizes and stores it, and a web app renders it back. No accounts, no third party
holding my data, two taps to log something.
apps script · google sheets · ios shortcuts · time triggers
When other people need accountsOnce something has real users it needs authentication and somewhere durable to write.
That's when I reach for a real front end and a hosted database instead of a flat file.
react · supabase · google oauth · vercel
When the deliverable is a document, not a pageSometimes the answer has to arrive as a PDF in someone's inbox, split by who's allowed
to see what. Generate the HTML, render it to PDF, distribute it on a schedule with
permissions attached.
python · colab · weasyprint · role-based access
The kit
What I actually use
PythonData pulling, cleaning, transformation, and PDF generation. Standard
library where I can, so there's less to break later.
SQL & BigQueryWhere the questions get answered before anything gets
built. Most analysis ends here rather than in a dashboard.
Google Apps ScriptThe glue for anything living in Sheets, Gmail, or
Calendar. Time triggers, web apps, and endpoints that phones can post to.
SalesforceThe source system at work. Reports and exports feeding pipelines
that get information to people who don't have a seat license.
GitHub ActionsScheduled jobs without a server. If something needs to happen
every week whether or not I'm awake, it happens here.
HTML, CSS, JavaScriptSingle-file pages, no build step. Charts drawn as SVG
rather than pulled in as a library.
Claude & Claude CodePair programming and review. It makes ambitious
projects tractable, and it's wrong often enough that I still have to understand what
I'm shipping.
How I decide
Four rules I keep coming back to
Deployed with a public URL, or it isn't doneWorking on my machine doesn't count. If a person can't click it, it doesn't exist.
Say what's missingWhen a source has holes, the page says so. An empty cell that admits the gap is worth
more than a filled one that hides it.
Fewer moving partsNo server unless something genuinely needs one. Every piece of infrastructure is
something that can break while I'm not watching.
Answer one question wellEvery tool here exists because I wanted to know one specific thing. The ones that
tried to do more are the ones I stopped opening.