Stop Chasing JSON Exports: Collecting Feedback in a Shared Store

I spend a lot of my day job collecting structured feedback from people: review these stories, adjust these estimates, answer these open questions. For years the mechanics of that were worse than the work itself. Build a form, send it out, wait for files to come back, merge them, argue about which version was newest.

A few weeks ago I changed how I do it, and the change was smaller than I expected. A Claude artifact (a page published to claude.ai) can carry its own small shared database. Answers go into that database instead of each reviewer's browser, everyone sees the same copy live, every entry is tagged with who made it, and Claude can read the results back without anyone exporting anything.

This post is how I got there, what it looks like in practice, and how to ask for it yourself.

What I used to do

The old approach was a self-contained HTML page. Claude Code built it with the questions baked in, reviewers filled it in, and an Export button downloaded a JSON file they emailed or messaged back to me. In the meantime, their answers lived in their own browser.

It worked, in the sense that files eventually arrived. It failed in every way that mattered:

Problem	Why it hurt
Answers live in one browser	Switch devices, clear the cache or open a private window and the work is gone
Nobody sees anyone else's answers	Reviewers duplicated or contradicted each other without knowing
Someone has to remember to export	Late or missing files, and me chasing people
N reviewers means N files	Manual merging, conflicts, "which one is latest?"
No reliable attribution	"Who said this?" depended on a file name or the email it came in on
No history	When an answer changed, the previous one was gone

What I do now

The page is still an artifact. The difference is that when it's published, it declares three runtime capabilities:

Capability	What it gives the page	How I use it
`db`	A shared database that lives with the artifact, updates live, and survives republishing	Feedback items and hour adjustments are saved here
`user` (profile scope)	Who is viewing: an opaque ID, plus display names for people in my organization	Each entry stores the author's ID; names show next to entries
`downloads`	A save-file prompt the viewer confirms	"Export JSON" and "Download spec"

The data flow is three steps:

A reviewer clicks Save and the page writes to the artifact's database.
Every open copy of the page updates within seconds.
Claude reads the store directly from Claude Code when I ask it to. No export step.

What that buys me:

One source of truth. One store, no files to merge.
Attribution. Every entry records the author and time. Status changes record who made them and when.
A trail. Changing an estimate keeps the current value per item and also posts a comment like "Hours 50–79 → 60–90. VPN work", so history isn't overwritten.
Live collaboration. Two reviewers see each other's comments as they land.
Claude reads results directly. "Read the feedback on the review page and update the backlog" works as written.
Answers survive republishing. I can fix the page or add a feature while the answers stay put.

How the prompting actually went

I didn't set out to build this. The sequence was ordinary, with one question in the middle that mattered more than the rest.

The original ask. "Build an HTML page where my colleagues can review the stories by epic, request adjustments to scope or contents, and export to JSON so we can ingest the commentary again." Claude loaded its artifact-capabilities guidance and chose a shared database over browser storage, because several reviewers needed one set of answers. It declared db, user and downloads, kept the JSON export anyway, and after publishing checked once that the store was reachable and empty.
"Can someone see the requirements tied to each story?" Requirement IDs became clickable cards. Content only, no storage change.
"Download the full spec, a structured way to adjust hour ranges, totals at the top, sticky header." Hours became a second collection, one current value per story. Each change also posts a comment, so there's a trail. The header totals baseline and adjusted hours live for everyone.
"Do feedback and estimate changes save on the artifact or on the user's computer? I'm sharing this with multiple people." This was the question. The first version quietly fell back to browser-only storage whenever it couldn't identify the viewer. Claude changed the page to use the shared store whenever it's reachable, and the header now says either "Shared live with all reviewers" or "Not shared: this browser only". Viewers who can't save get a clear message.
"What access does a viewer need to write?" Claude tested writes at different access levels. A signed-in viewer who can use the page can write. Someone shared view-only cannot.
Polish. A summary panel at the top, and a fix so clicking a requirement no longer jumped to the top of the page.

The lesson: ask early and directly whether answers are shared or per-browser, and have Claude show that status on the page itself. If I'd skipped step 4, I'd have shipped a page that looked collaborative and wasn't.

How to ask for it

You don't need to know the capability names. Describe the behavior and Claude declares the right ones. Here's the prompt I now copy and adapt:

Build an artifact where [audience] can [answer these questions / review these items / approve these decisions]. Save every answer to the artifact's shared store, not the browser, so everyone I share it with sees the same answers live. Record who made each entry and when, and keep a history when something changes. Show on the page whether it's saving to the shared store. Add a JSON export as a backup. After you publish, confirm the store works, and tell me what access people need to save.

Useful follow-ups once it's live:

"Read the responses from [artifact link] and summarize them by owner."
"Mark these items resolved in the store."
"Add a field for X without losing existing answers." (Answers survive republishing, so this is safe.)

Where it fits

Anything where several people answer in place and you want to watch progress without a round-trip:

Discovery questionnaires and open-question registers. A natural fit for a spec's open-questions list.
Requirement, scope or estimate review. Comment by item, adjust hours with a reason, keep live totals.
Decision logs and sign-off checklists. Who approved what, and when.
UAT feedback and defect intake. Each tester's notes are attributed and visible to the team.
Sprint or prioritization voting. One vote per person, tallied live.
RAID logs shared with a stakeholder during a project.

If the deliverable is mostly prose people will edit as text, use a normal document instead.

Limits and cautions

Topic	What to know
Access to save	People must be shared on the artifact above view-only. View-only viewers can read but not save. I haven't confirmed which Share-menu option maps to which level, so test with one person first.
Names outside your organization	Outside entries still save and are tagged with an ID, but their names show as "Someone". For external pages, add a "Your name" field or ask Claude to label guest entries.
External sharing	People outside the organization need an email invite (or "anyone with the link", if offered). Artifacts are private until you share them.
Sensitive data	I work with healthcare-adjacent systems, so my standing rule is never to collect PHI in these pages: no patient names, DOB, diagnoses or member IDs. Use identifiers and synthetic examples. The same discipline applies to any regulated data.
Confidentiality	One artifact per engagement and per purpose. Never reuse a page or its store across organizations.
Concurrent edits	Last save wins on the same field. Keep the history trail on anything that matters.
Fallback	If a page can't reach its store (a downloaded copy, or not signed in), it saves to that browser only. That's why the status indicator matters.
Size	Generous for this use. My store reported a limit of 25,000 documents. Files over ~16 MB can't be attached.
File types	PDFs attach for download. Word files can't be attached directly; I stored the file as text and rebuilt it on download.
Backup	Keep the JSON export. It's the hand-off format if anything needs to leave the platform.

What the finished page looks like

The backlog review page I ended up with has:

The stories: 62 stories grouped by epic, with clickable requirement details.
Feedback: comments on scope, content or estimates, a question type, or "looks good".
Hours: structured adjustments per story, each with a reason.
Totals: live baseline vs adjusted totals in a sticky header.
Downloads: the full spec as Word or PDF.
Sharing status: a "shared live" indicator.
Export: JSON of all feedback, hour changes and totals.

Reviewers' work lands in one place, attributed, and Claude folds it straight back into the backlog, the Jira import and the spec. Nobody exports anything, and I haven't merged a JSON file since.