Internal Dashboards With Claude Artifacts: The No-Code Prompt Pattern Non-Tech Founders Are Actually Using

The most common question I get from non-technical founders in 2026 is some version of: I need a dashboard, I don't want to pay for Metabase, I don't want to hire a developer for three weeks, and I don't want to live inside a spreadsheet anymore. For a very specific slice of problems, the answer now is Claude Artifacts. Not a Notion database, not a Glide app, not a Bubble workflow. An Artifact, pinned inside your Claude account, that you open in a browser tab and that remembers your data between sessions.

The reason most founders have not tried this yet is that the Artifacts feature has changed three times in eighteen months and the tutorials on page one of Google describe the 2024 version, which was a throwaway preview canvas. That version could not save state, could not talk to the Claude model from inside the rendered app, and could not be shared as a link. The current version can do all three. What follows is the exact prompt pattern we use with founder clients who want a revenue board, a pipeline tracker, or a content calendar live in under an hour, the storage behaviour that almost nothing online documents properly, and the point at which you should stop fighting the platform and commission a real internal tool.

What A 2026 Artifact Actually Is

An Artifact is a small React or HTML application that renders in a panel beside your Claude conversation. You describe it in natural language, Claude writes the code, the code runs in a sandboxed iframe inside claude.ai, and you interact with the result. The three changes that matter for dashboard use are these. First, Artifacts now persist state. The sandbox has access to localStorage, which is scoped to the artifact and your logged-in user, and the Artifact runtime itself serialises certain state between sessions, so numbers you typed in last Tuesday are still there on Friday. Second, Artifacts can call the Claude model from inside the rendered app, meaning a dashboard can have a natural-language input box that rewrites its own contents when you type add a churn column. Third, Artifacts can be published to a shareable URL that other Claude users can open, each with their own private copy of the data.

What an Artifact is not is a web application. It cannot make outbound network requests to Stripe, HubSpot, Google Analytics, or your own database. It cannot authenticate anyone except through Claude itself. It cannot run on a schedule, receive a webhook, or push a notification. It cannot be embedded inside another site with your company's login. These boundaries are the whole reason the prompt pattern below works for some problems and fails instantly for others.

The Persistence Trick Most Tutorials Miss

Search for claude artifacts persistence and the top results will either tell you it is impossible or give you a snippet that pastes data into the prompt on every use. Both are wrong for the current build. Inside the Artifact sandbox you have a working window.localStorage, and unlike a plain web page this storage survives across Claude sessions, browser restarts, and even device switches for the owner of the Artifact. The one rule that trips founders up is that storage is per viewer, not global. If you share your revenue dashboard with your cofounder, they see your code, but they do not see your numbers. They get an empty board and their own private copy of the storage. For a personal founder tool this is fine. For a team scoreboard it is a dealbreaker, and this is the first and most common reason people outgrow Artifacts.

The way to make persistence reliable is to tell Claude about it explicitly in the prompt. Do not assume the default generated code will save anything. Do not assume it will load on mount. The following phrase is the one we use on every dashboard build, verbatim:

Persist all user-entered data to localStorage under the key dashboard_v1. On mount, hydrate state from that key. On every change, debounce a save back. Also render a small Export JSON and Import JSON pair of buttons so I can back up and restore the data.

Adding those two sentences turns a pretty but amnesiac Artifact into something you can actually use for six months.

The Revenue Dashboard Prompt, Annotated

Here is the full prompt template we give founders for a monthly revenue dashboard. Paste it into Claude, replace the bracketed placeholders, and accept the Artifact it produces.

Build an interactive revenue dashboard as a single React Artifact. The business is [one sentence description, for example a B2B SaaS selling a compliance product to mid-market US healthcare companies]. Currency is [USD]. Time granularity is month, with a selectable range covering the last [18] months through the current month.

At the top of the dashboard render four KPI cards: Monthly Recurring Revenue, New MRR this month, Churned MRR this month, and Net Revenue Retention over the trailing three months. Below the cards, render a line chart of MRR by month, a bar chart of new versus churned MRR by month, and a table of the ten largest accounts with columns for account name, plan, MRR, signed date, and status.

The data source is manual entry. Render an Add Month form and an Add Account form. Each form writes into state and persists to localStorage under revenue_dashboard_v1. On mount, hydrate from that key. Debounce saves. Include Export JSON and Import JSON buttons so I can back up the whole board.

Style the dashboard with a clean modern look, rounded cards, a muted neutral palette, and a single accent colour of [#1E90FF]. Use Recharts for both charts. Make the layout responsive down to a 13-inch laptop screen. Flag any KPI card red when the value is negative or worse than the previous month.

Do not make any outbound network calls. All computation happens inside the Artifact.

The reason every one of those paragraphs is there can be reverse-engineered from watching Claude get it wrong when you leave them out. Without the schema, the dashboard invents fake data and you spend ten minutes wiping it. Without the persistence sentence, your entries vanish on refresh. Without the explicit Recharts instruction, Claude occasionally chooses a charting library that is not whitelisted in the sandbox and the Artifact silently fails to render. Without the no outbound calls line, Claude sometimes writes a dead fetch() to a demo URL that throws an error in the console and scares the founder into thinking the tool is broken.

The Pipeline Tracker Variant

The same skeleton rewires cleanly into a sales pipeline tracker. Swap the KPI cards for Pipeline Value, Weighted Pipeline, Deals Created This Week, and Deals Closed Won This Month. Swap the line chart for a funnel chart with stages Lead, Qualified, Demo, Proposal, and Closed Won. Swap the accounts table for a deals table with columns account, stage, amount, probability, owner, and next step. Everything else stays identical, including the persistence line and the export buttons. The prompt we give founders reads:

Build an interactive sales pipeline tracker as a single React Artifact. Stages are Lead, Qualified, Demo, Proposal, Closed Won, Closed Lost. Each deal has account name, amount in [USD], stage, probability percent, owner, created date, and next step text. Render a funnel chart by stage value, KPI cards for total pipeline, weighted pipeline, deals created in the trailing 7 days, and deals closed won in the current month. Render an editable table of all open deals sorted by amount descending, with inline stage change. Persist everything to localStorage under pipeline_v1, hydrate on mount, debounce saves, include Export and Import JSON buttons. Flag deals where next step is blank or last updated more than 14 days ago in red.

The stale-deal flag is the single feature that has made founders keep the Artifact open in a pinned tab instead of reverting to a spreadsheet. It is the kind of small behavioural trigger that would take a paid CRM three plan upgrades to reach.

The Content Calendar Variant

Content calendars are the easiest of the three because the data is simple. Title, channel, status, publish date, owner, one link field. The useful part is what you ask Claude to compute on top of it. A prompt we have shipped repeatedly is:

Build a content calendar Artifact. Each entry has title, channel (blog, LinkedIn, X, newsletter, podcast), status (idea, drafting, in review, scheduled, live), publish date, owner, and link. Render a month grid view with entries on the day of their publish date, colour coded by channel. Below the grid render a table grouped by status. At the top render KPI cards for items live this month, items scheduled for the next 14 days, items stuck in review for more than 7 days, and items with no owner assigned. Persist to localStorage under content_calendar_v1. Hydrate on mount, debounce saves, export and import JSON.

The stuck-in-review card is the version of this dashboard's stale-deal flag. Without it, a calendar is a prettier Airtable. With it, it becomes a weekly decision tool.

The Natural Language Edit Loop

Once the Artifact is rendering correctly, the fastest way to iterate is to simply keep typing to Claude in the same conversation. Add a filter by owner. Show me year over year MRR change underneath each KPI. Change the accent to a darker blue. Add a column for LTV. Claude rewrites the Artifact code, the panel refreshes, and your persisted data is still there as long as the storage key has not changed. If you ever need to wipe state, add a Reset Data button to the dashboard with a confirm dialog, rather than clearing localStorage by hand through browser dev tools, which most non-technical founders are understandably unwilling to touch.

One rule of thumb that keeps the loop productive. Edit in small steps and accept each diff before asking for the next one. Asking for six unrelated changes in one message is the fastest way to get an Artifact that renders blank and has to be rebuilt from the last good version. The Artifact history panel does preserve previous versions, but rolling back is slower than preventing the rebuild in the first place.

Where Artifacts Stop Working

There is a hard edge you will reach, and it is better to plan for it than to discover it the week you hit it. The first wall is multi-user shared data. The moment two people need to look at the same live numbers, Artifacts are the wrong tool, because storage is per viewer and there is no shared backend. The second wall is live integrations. If you want MRR to update itself from Stripe, pipeline to sync from HubSpot, or content status to pull from Notion, Artifacts cannot make those calls and never will inside the current sandbox model. The third wall is customer-facing use. Anything a customer is meant to open requires authentication that is not a Claude login, and Artifacts offer no such layer. The fourth wall is size. Artifacts cap at a few hundred kilobytes of code, so a dashboard with fifteen views, a heavy charting library, and rich table interactions will eventually hit a limit and start dropping features quietly. The fifth wall is embedding. You cannot drop an Artifact into your own marketing site, your investor update portal, or a shared team wiki with SSO.

When a founder client of ours hits one of these walls, the conversation shifts. The Artifact was worth building because it proved the shape of the dashboard, the metrics that mattered, the fields the team actually used, and the visuals people actually read. That is a specification document you could not have written on a whiteboard. With it in hand, a real internal tool is a two to four week build rather than a two to three month exploration.

When To Commission A Real Internal Tool

The decision is straightforward. If you are the only person who needs the dashboard, Artifacts wins. If you need two to five people watching the same live numbers, and you want the numbers to update themselves from Stripe or HubSpot or your product database, and you want to open it at a yourcompany.com subdomain behind your existing login, you need a real internal tool. WitsCode builds exactly that. We take the Artifact you already have, treat it as the spec, and ship a multi-user version with live integrations, auth, and a custom domain in the timeframe a single Bubble learning curve would otherwise consume.

If you have an Artifact prototype working and you are hitting the multi-user, live-data, or auth wall, book a WitsCode internal-tool scoping call and we will turn it into production software.