AI Workflow Notes · AI Workflow MOFU
One-Day Civic Tech Demo: AI Rapid Prototyping
How a policy staffer and I used Claude Code to ship a childcare map, open repo, and red-teamed deck in 7.5 hours.
The brief arrived as one sentence: “help me write a childcare policy spec.”
That was it. No data, no scope, no wireframes. A policy staffer in Taoyuan, Taiwan needed something concrete to bring into a policy discussion, and “a spec” was as precise as the request got.
One working day later, 7.5 hours on the clock, we had a live interactive map of all 194 licensed childcare facilities in the city, an MIT-licensed GitHub repo any city can fork, and a policy deck that had survived a red-team pass which caught a real factual error before anyone outside the room saw it. Two people did this: the staffer and me, with Claude Code doing the heavy lifting.
Here is the full breakdown.
What shipped in 7.5 hours
Seven deliverables left the building that day:
- A policy spec, v1 through v3. The one-sentence brief became a real spec, then got revised twice as the research and the demo taught us things.
- Research on 11 European childcare platforms. What other governments already ship, feature by feature.
- A Taiwan gap analysis. Where local reality diverges from those 11 platforms, and which gaps a city could actually close.
- An open-source GitHub repo. MIT license, white-label by design.
- A working demo site deployed on GitHub Pages. A URL you can open right now.
- A policy deck in both HTML and Markdown, so it works in a meeting room and in a repo.
- A red-team-tested conclusion report. A subagent attacked our own claims before the deck went out. It found one that was wrong. More on that below.
The demo itself
The map covers all 194 licensed childcare facilities in Taoyuan. For each facility: rating, monthly fee, licensed capacity, and real-time vacancy. Parents get a filterable map instead of a PDF list buried three clicks deep on a government site.
The technical shape matters as much as the features. It is a pure static site: no backend, no database, zero API keys to manage. Data comes from Taoyuan government open data (datasets 168379 and 168385) plus the official childcare API, and the geocode cache is committed to the repo, so clone-and-build requires zero keys. The whole thing is white-label: another city forks the repo, edits the files in site/config/, and deploys its own version.
10 to 14 days, compressed into one
Run this project the traditional way and the calendar fills up fast. Requirements meetings. Vendor scoping or an internal ticket queue. A formal data request. A development sprint. Review cycles. For a demo of this scope, 10 to 14 working days is a fair estimate, and that assumes everyone answers email quickly.
Our day, roughly:
| Time | What happened |
|---|---|
| 09:00-09:45 | One-sentence brief becomes spec v1: who it serves, what decision it supports, what data exists |
| 09:45-11:00 | Research pass: 11 European childcare platforms, then the Taiwan gap analysis |
| 11:00-12:30 | Data pipeline: pull datasets 168379 and 168385, wire up the official childcare API, geocode and commit the cache |
| 13:00-15:00 | Build and deploy the static demo to GitHub Pages; spec v2 |
| 15:00-16:15 | Policy deck in HTML and Markdown; spec v3 |
| 16:15-17:00 | Red-team pass, one correction, final conclusion report |
Same scope. Same data sources. The difference is what the two humans spent their hours on.
What actually made “one day” possible
Three things, and none of them is “we prompted harder.”
Claude Code worked as a skilled junior. It read the datasets, wrote the pipeline, built the site, drafted the research and the deck. Like a good junior, it produced usable first drafts fast and mostly needed decisions from us rather than corrections.
The human was the decision-maker, not the typist. The staffer spent the day answering questions software can’t: what counts as a fair comparison for Taiwan among those 11 platforms, which spec revisions matter, how the deck should frame its conclusions. Every hour a domain expert spends on judgment instead of formatting is an hour the day gets back.
The pipelines already existed. This part is the honest asterisk on the headline. My studio runs on a stack of Claude Code skills built over months; the public version lives at claude-code-skill-stack. Research agents, deploy flows, and the red-team step were reused, not invented at 9 a.m. Anyone selling you “just prompt ChatGPT and ship in a day” is skipping this paragraph. The starting point is the product. The day is just when it becomes visible.
The red-team step
Before the deck went anywhere, a fresh subagent got a single job: attack every claim in the report and the deck, and try to break them against the underlying data.
It caught one claim that was wrong. We corrected it, re-ran the pass, and only then marked the report done.
I want to be precise about why this matters. AI-generated research reads confident whether it is right or not, and a policy deck is exactly the kind of artifact where one wrong number quietly becomes someone’s talking point. So verification is a scheduled step in the pipeline with its own time slot, 45 minutes of the 7.5 hours. That one caught error paid for all of them.
The Method, at full speed
This day was the Solo Stack Method running end to end: Signal (a vague one-line brief, taken seriously), Strategy (spec v1 to v3, revised as we learned), Skill (the agent pipelines that already existed), Ship (a public URL and an open repo before dinner). Nothing about childcare policy is special here. The same loop ships client work in my studio every week.
If you want to poke at the result, fork the repo and stand up your own city’s version. And if you want your team to build at this speed with its own data and its own guardrails, that capability is what I help organizations install: work with me.
FAQ
Is a one-day demo production-ready?
No, and it does not claim to be. Production for a government service means accessibility audits, data-refresh agreements, uptime commitments, and someone on call. What the one-day version does is collapse the riskiest unknowns of that longer project: it proves the open data is sufficient, the official API works, and residents would get real value from the result. A city that later decides to go to production starts from a working, MIT-licensed codebase and a spec that survived three revisions, instead of starting from a slide.
Could a non-programmer replicate this?
Partly, and the repo is designed for that. Clone-and-build needs zero API keys because the geocode cache ships with the code, and a city that wants its own version edits the files in site/config/ rather than touching application logic. Forking is genuinely non-programmer territory. The one-day pace, though, came from pairing: a domain expert making fast decisions next to someone who runs AI coding pipelines daily. A non-programmer alone with Claude Code would get further than you might expect, but should budget more than a day.
Why open-source it?
Three reasons. Public money produced the underlying data, so tools built on it should stay public. The MIT license and white-label structure push the marginal cost of the next city toward zero: fork, edit site/config/, deploy to GitHub Pages. And inside the policy conversation, an open repo is more persuasive than a deck, because a skeptical councillor or journalist can read the code and check the sources (Taoyuan datasets 168379 and 168385, plus the official childcare API) rather than taking our word for anything.
What did the human actually do all day?
Decide. The staffer defined who the map serves, judged which of the 11 European platforms were fair comparisons for Taiwan, approved each spec revision, and set the framing of the policy deck. I directed the pipeline: which agent ran when, when the research was deep enough, when the demo was good enough to deploy, and when to trigger the red-team pass. Neither of us spent the day typing code. The output tracked the quality of our decisions, which is exactly the shift the Solo Stack Method describes.