When “It Worked in Testing” Isn’t Enough

A tool that passes every test and still fails in production is one of the more expensive lessons in software development, and it just played out inside a routine internal build. A developer on the ZTS Infotech team built a support-ticket tracker inside Claude Artifacts, wired it to Slack and Trello, and had Claude’s own AI draft ticket responses automatically. It worked beautifully in testing. The full workflow behaved exactly as expected. One week later, every stored ticket was gone.

The cause was not a bug, an outage, or bad code. It was a single checkbox.

The Setting That Decides Whether Anything Gets Saved

Claude Artifacts, Anthropic’s environment for building small interactive tools directly inside a conversation, offers persistent storage so a tool can remember data between sessions. That storage only activates once the artifact is published. The developer had built the tracker, tested it, and connected it to Slack and Trello — but never published it. Every ticket the tool appeared to save was living inside a session that resets the moment the browser tab closes.

Why “Unpublish” Is More Dangerous Than It Sounds

The sharper risk sits one step further. If a published artifact is later unpublished, say to clean up an old draft, the stored data does not pause or go dormant. It is permanently deleted. A setting that looks like routine housekeeping is, underneath, an irreversible data-loss switch — which makes the build order around it a genuine business risk, not a cosmetic detail.

The Build Order That Actually Works

The fix is not a workaround; it is a sequence, and it runs backward from how most tutorials teach the same feature — start with the AI, then wire it up, worry about storage later.

Step 1 — Publish first, before anything else. Build the artifact, publish it immediately even in its most basic form, close the tab, reopen it, and confirm the data survived. Nothing else proceeds until this step holds.
Step 2 — Add the AI layer. Only once storage is confirmed reliable does the artifact call Claude’s own API to draft a reply or summarize a ticket on its own.
Step 3 — Connect external systems through MCP. Slack, Trello, Gmail, and Google Calendar get wired in via the Model Context Protocol at this stage, not before. A connected tool with no confirmed memory underneath it is, in effect, built on sand.
Step 4 — Add live, auto-refreshing data last. A live view only matters once the underlying data is known to be reliably stored. A live view of unreliable storage is just a live view of nothing.
Why This Matters for Business Leaders
The instinct to build the impressive part first — the AI layer, the integrations, the live dashboard — is natural and almost universally how demos get built. It is also exactly backward for anything meant to hold real client or customer data. The ZTS Infotech incident is a useful case study precisely because nothing about it was exotic: a competent developer, a working demo, a standard integration stack, and a foundational setting left unchecked.
Building on Confirmed Storage, Not Assumed Storage
Any team shipping internal tools or client-facing prototypes on Claude Artifacts, or any similarly flexible AI building environment, should treat data persistence as a fact to be verified, not assumed. That means testing the storage layer in isolation — save something, close everything, reopen it, confirm it is still there — before a single integration or AI feature is layered on top. It is a small discipline that costs minutes and prevents the kind of failure that erodes client trust in a single week.
The Fine Print Worth Knowing
Claude Artifacts storage is capped at 20 megabytes per artifact, text only, and requires a paid Claude plan — Pro, Max, Team, or Enterprise. It is not available on the free tier. Teams evaluating Artifacts for anything beyond a quick prototype should factor these limits into scope from the outset, rather than discovering them mid-build.
Expert Perspective
What makes this incident worth reporting is not the specific product feature; it is the pattern. AI-assisted development tools make it remarkably easy to build something that looks finished — a working UI, live integrations, an AI layer producing sensible output — well before the unglamorous foundation underneath it has actually been verified. Speed and polish are not the same as reliability, and the gap between them is exactly where incidents like this one happen.
The more durable business lesson is procedural: verify the foundation before building on top of it, in that literal order, every time. ZTS Infotech’s internal standard now reflects that directly — every internal tool built in Artifacts for a client gets step one confirmed, tab closed, tab reopened, data intact, before step two is ever touched. That is a low-cost, easily repeatable check, and it is the difference between a tool that survives contact with real use and one that quietly loses a week of customer data.
Key Takeaways
Claude Artifacts’ persistent storage only activates once an artifact is published; building and testing it unpublished means nothing is actually being saved.
Unpublishing an artifact later does not pause its stored data — it permanently deletes it.
The correct build order runs backward from convention: publish and confirm storage first, then the AI layer, then MCP connections, then live auto-refreshing data last.
A connected integration with unverified storage underneath it is, functionally, built on sand.
Storage is capped at 20MB per artifact, text only, and requires a paid Claude plan (Pro, Max, Team, or Enterprise) — not available on the free tier.
The failure in this case was procedural, not technical — a reminder that fast, impressive AI-built demos still need their foundation verified before real data touches them.
Teams building internal or client tools on Claude Artifacts should confirm persistence in isolation, before adding any AI features or integrations.
Conclusion
Nothing about this incident required a rare mistake or a hidden bug — just a natural build order applied to a tool where that order happens to be inverted. As more teams reach for AI-native environments like Claude Artifacts to ship internal tools quickly, the operative discipline is not writing better code; it is confirming, in a fixed and repeatable order, that the foundation holds before anything is built on top of it. Business leaders greenlighting these builds should ask one question before any other: has step one actually been confirmed?