How to share a tool Claude built with your team

You asked Claude for a tool and got one. It works, you have used it twice, and now a colleague has asked you to send it over. The question that follows is smaller than it sounds and harder than it looks: where does the thing actually live?

There are two answers. The first one is better than most people expect, so start there.

Leave it as an artifact, if it fits

An artifact is not a code snippet. Anthropic describes artifacts as a way to turn ideas into shareable apps and tools, rendered in a window separate from the conversation. A calculator built as an artifact is a working calculator.

The best published account of using them this way is Pragnesh Palsana’s post on building internal tools without a dev team. Their team has no internal tools developer. They built a client onboarding checklist generator that took two sessions, and a meeting notes formatter that took one. The pricing calculator replaced a Google Sheet with three years of formulas nobody wanted to touch.

If your tool is shaped like theirs, an artifact is the right answer today, and you should use it. What the rest of this covers is where that answer runs out, which is worth knowing in advance rather than during the week it happens to you.

Where artifacts stop

The Medium post is honest about this, and its limits section is the most useful part of it. Three things are named there, and all three are correct.

Artifacts do not persist data. Anything that has to remember something between sessions needs a real database somewhere, and the workaround is exporting to CSV, which the author calls ugly but functional.

An artifact is a single-user browser tool. If two people need to edit the same data, you are back to needing a real app.

And there is a complexity ceiling, somewhere around moderately complex, past which iterating with Claude takes longer than building the thing properly.

Add two more that follow from the same shape. An artifact runs in the browser of whoever opened it, so it cannot reach your billing system or your data warehouse by itself. And it cannot run when nobody is looking, so “every Monday” still means a person remembering it is Monday.

One more is worth checking before you paste the link into Slack. If you built the tool on a personal plan, Anthropic’s documentation on publishing and sharing artifacts is clear that publishing makes it publicly available to anyone with the link. Sharing privately within an organization is a Team and Enterprise feature. On Free, Pro or Max, sending your tool to a colleague and putting it on the open internet are the same action, which is fine for a meeting notes formatter and not fine for anything with salaries in it.

That is not a criticism of artifacts. It is a description of what a chat window is. None of it matters until your tool crosses one of those lines, and then all of it matters at once.

If the tool came from something other than Claude

Everything above assumes you have an artifact to fall back on. Plenty of people do not, because this is a feature each vendor ships or withdraws on its own schedule.

ChatGPT is the case worth knowing about. Canvas was its closest equivalent, and OpenAI’s own model release notes record its removal in the GPT-5.5 Instant update of May 28, 2026: canvas is no longer available in GPT-5.5 Instant or GPT-5.5 Thinking, and writing and coding now come back inside the chat response as writing blocks and code blocks. Paid users can keep using canvas through legacy models for a limited time, until those models are sunset too.

What remains is the shared link, and it is a different object than it looks. OpenAI’s shared links FAQ describes it as a snapshot of the conversation up to the point you shared it, and notes that deleting the original conversation deletes the link. Your colleague opens it and reads your chat. They do not get the tool. Clear that conversation out of your history in six months and their bookmark stops working.

Gemini is the exception, so do not read this as a rule about chat assistants. Google’s Canvas documentation has a share step for apps specifically, handing you a g.co/gemini/share link to paste wherever you like.

The useful lesson is not which vendor is ahead this month. It is that a tool living inside an assistant has a lifespan set by that assistant’s roadmap. OpenAI shipped this capability and then took it out of its current models, and nobody using canvas for a weekly report got a vote.

When the tool is a file instead of a page

The other common case is that what you have is not an artifact at all. It is a folder, or a single script, sitting in your Downloads folder.

That is a different problem with different answers, and it depends mostly on what language the thing is written in. We wrote up the Python version separately: how to share a Python script with coworkers who do not have Python. If your thing is a web project and the obstacle is that every guide starts with “push it to GitHub,” start with putting an app online without a repo instead.

When it has to be a place

Here is the short test for whether you have outgrown the chat window. The tool needs an address of its own once it has to remember something between visits, reach a system that is not in the browser, run on a schedule, or open for people who are not on your company’s Claude plan. Any one of those turns this into a hosting question.

We surveyed the options for exactly this in where do you actually put it, including the ones that will serve you better than we can today. The short version is that most platforms will run your code and almost none of them will put your company’s sign-in in front of it.

Where Sploot is aiming

Since this is our blog: the bet is that the folder should be the input, and that sign-in with a work email should be there before the app boots rather than as something you wire up afterwards.

Sploot is in private beta and there is nothing to log into yet, so treat that as a statement of intent rather than an offer. If you have a colleague waiting this week, the artifact you already have is very likely the right answer for this week.

The reason to think about where the tool lives is not that artifacts are bad at their job. It is that a tool your team comes to depend on should not have its future decided by a line in somebody else’s release notes.