The first big task from the enterprise client landed this week. The first proper one. Big enough that if it wanted to it could become a piece of software in its own right, its own SaaS, with paying users outside this client.
I am seeding data by hand. Pasting a small set of representative entries into a Claude artifact: emails the team would actually forward into a shared inbox, social-media posts from a handful of trusted feeds. Sixty to ninety minutes of typing, copying, cleaning. By morning the artifact will hold a working seed of real-shape data, and the research team will be able to query it live in front of me.
I had seen Claude artifacts in passing for months. I did not know what they were for, or how I would actually use one. The penny dropped this week.
What a Claude artifact is
A Claude artifact is a self-contained page (usually HTML, sometimes a small interactive React component) that Claude generates inside a conversation and that the user can keep coming back to. Take a one-off answer and turn it into a view you can re-open, refresh, and interact with. The artifact has access to whatever connectors Claude is wired up to, so when it loads it can pull fresh data from a shared mailbox, a calendar, a project tool, a database. The page persists across sessions. The data inside the page does not.
A normal chat exchange is ephemeral. An artifact is a tiny living dashboard. It is not a SaaS. It is not a webapp behind auth. It is a one-file page that Claude wrote and that the user opens whenever they want a fresh look at the same shape of data.
How I'm using one for tomorrow's demo
The premise of the engagement is a custom AI workflow that lets a research team collaborate without giving up the freedom to use Claude (full Opus 4.7 power) for their own queries. Smart, domain-deep researchers do not want to be confined to my idea of what a "report" should look like. They want to capture data, query it freely, and build their own dashboards from their own questions.
So as the workflow designer my job is not to design the reports they will want. My job is to design the rails: separate the data into clean, named datasets, make those datasets trustworthy, and step out of the way. They build the reports.
For the proof of concept the rails are two pieces.
Piece one is a shared signals inbox. A mailbox the whole team has access to. When an email comes in that someone thinks is important (a regulatory note, a competitor announcement, a tip from a contact), they forward it to that inbox. I wire Claude to the inbox via a Microsoft 365 or Gmail connector. Now Claude can treat the contents of that inbox as a trusted, human-curated dataset. No scraping. No API plumbing. Just forwarding behaviour the team already does, redirected into a single source.
Piece two is a clean set of social-media feeds. Specific accounts the team already trusts as signal. Not a firehose. No API wrappers. For the PoC I cannot easily pull historical posts, so I am seeding the feed manually tonight. Ninety minutes of pasting representative posts into the artifact's data model. Once the artifact has a seed of data, it is a real demo, not a wireframe.
Both pieces feed the same artifact. The artifact lays the data out in a way the research team can poke at: filters, simple charts, the option to ask Claude follow-up questions over the seeded set. They will see, in the first ten minutes of the demo, what the workflow could feel like.
Why this is the right surface for a PoC
The first is speed. From "the client gave me the task" to "the client can see a working artifact" is a few hours of focused work. No DevOps, no auth, no database design, no deployment pipeline. The page lives inside the Claude session and renders in front of them.
The second is honesty. The artifact is a real piece of software running on real seeded data. It is not a Figma mock. It is not a slide deck. The team can click on it, query it, change a filter, and see what comes back. That is a different conversation than "here is a slide of what the dashboard could look like." It is a conversation about what they would actually use.
The third is options. After tomorrow, no matter what direction the team picks, I can move quickly. If they like the shape, the next phase is probably a small purpose-built tool. Most of which may not need a database at all, beyond user authentication. A few days of work and the research team is collaborating, querying, and surfacing ideas they could not surface before. If they want to take the workflow in a different direction, I have not over-built, and the artifact has earned its keep as a thinking tool.
Where else artifacts earn their keep
A few patterns I have come across, beyond the PoC demo. Recurring reports are an obvious fit: weekly metrics, an open-task tracker, a hiring pipeline view, anything you would otherwise paste into chat as a markdown table that the user will plausibly want refreshed next week. Status pages are the next family: a project board, a queue of inbound leads, a list of "things waiting on me," anything the user will want to glance at again. Interactive explorers come third: a page over connector data with filters and sorts, the option to ask Claude follow-up questions inline. Especially strong when you want the user to find their own answer rather than read yours. The fourth is single-purpose tools: a cost estimator, a pricing comparator, a small research-question utility the team keeps coming back to.
The thread underneath all four is the same: persistence, fresh data on every open, zero infrastructure.
The fractional-consultant angle
This is how a single fractional AI consultant ships in 2026. The engagement closed earlier in the month. By the second week I had the architecture scoped with the technical lead. By tonight I have a working seed of data in an artifact. Tomorrow morning I demo. The build itself, what tomorrow's surface actually does, is a few hours.
Two years ago this same delivery would have been a designer, a junior dev, a senior dev, a project manager, and four to six weeks. Today it is me, an artifact, and an evening of seeding. None of which means I will not bring specialists in once the direction is locked. The artifact just gets us to the direction first. Different jobs.
There is a related thread on this same engagement from the trip back from Madrid: speccing a personal AI assistant for the same kind of stakeholder. Different surface (an EA, not a research dashboard), same logic. Find the lightest real working object you can put in front of the human, and let them tell you what they actually want next.
I cannot share the artifact itself. The data inside it is the client's. What I can share is the shape of the idea. That is enough for the team to give me a clear next-phase direction tomorrow, which is the only thing I need from the meeting.
Pretty sure we will be able to dazzle.
Right. Back to seeding.
Monthly Revenues $11,800 | Clients 2 | Prospects 1 (will book once closed) | Employees: me
Day 35 of 365.