April 2, 2026 · How-to

How to share an app you built with Claude

You built a working app with Claude and now it's stuck on your screen. Here's the simplest way to get it onto a real link, with a login and saved data, so other people can actually use it.

You asked Claude to build something (a chore chart, a client intake form, a little dashboard for your team), and it worked. Then you hit the wall everyone hits: it only exists on your screen. The next thing you typed was probably some version of “okay, how do I get other people to actually use this?”

This guide answers that question. The short version: connect Backlit to Claude once, then ask Claude to publish the app. It comes back as a live link with sign-in and saved data already attached. Here’s the longer version, including the options most people try first and why they fall short.

The quick answer

To share an app you built with Claude so other people can use it, you need three things the chat doesn’t give you: somewhere to host it, a way to control who can open it, and somewhere to store the data people enter. The fastest way to get all three is to add Backlit as an MCP connector in Claude and ask it to publish the app. Claude does the rest in the same conversation and hands you a URL.

Why the app is stuck

When Claude writes you a single-page app, it’s usually one self-contained HTML file. That file runs beautifully when you open it on your own machine. But “open it on your own machine” is exactly the problem:

You can’t send someone a file and expect them to use it like a real app.
There’s no address, no something.com to share.
There’s nowhere for the data to live, so anything anyone types vanishes when they close the tab.
And if it’s even slightly private (a family budget, a team tracker), you don’t want it open to the whole internet.

So the app is finished, but unshareable. The gap between “it works for me” and “my wife / my team / my customers can use it” is the entire job.

The options people try first

Emailing the HTML file. This almost never works. The recipient gets a file, not an app; nothing is saved; and anything that talks to a server breaks. Fine for a demo, useless for something people return to.

Screen-sharing it. You can show someone, but they can’t use it. The moment you close your laptop, it’s gone.

Putting it on a static host (Netlify, Vercel, GitHub Pages). Closer. Now it has a URL. But these are build pipelines aimed at developers. They host your files; they don’t give you a login or a place to save per-user data. You’d be back in the chat asking Claude to help you wire up authentication and a database, which is a project in itself.

Standing up a backend (Supabase, Firebase). This can do everything, and that’s the problem. It’s a real backend you have to design, connect, and maintain, for what might be a ten-minute app.

Each of these makes you do work that has nothing to do with the thing you actually built.

The simplest path: ask your assistant

Backlit exists to close that gap from inside the conversation where you built the app. It’s a host that comes with sign-in and per-user storage baked in, and it plugs into Claude as an MCP connector, so Claude can publish your app for you.

Here’s the whole flow:

Connect Backlit once. In Claude, go to Settings → Connectors → Add custom connector and paste the Backlit MCP URL: https://mcp.backlit.run/mcp. Sign in to authorize it. (You only do this once.)
Ask Claude to publish. In the same chat where you built the app, say something like “Deploy this to Backlit and give me and my team access.”
Claude wires it up. It stages the app, attaches sign-in and storage, and publishes it to a live address like bright-ledger.backlit.run.
Share the link. Claude hands you the URL with the right people already on the allowlist. Send it. They sign in, they use it, their data is saved.

No build step, no servers, no copying things between tools. You stayed in the chat the whole time.

What you actually get

A real link. Your app lives at its own address on backlit.run (or your own domain on a paid plan).
Sign-in, handled. Magic-link, Google, or Microsoft sign-in, limited to the emails or domain you choose. Private by default. Nothing is exposed to the public unless you decide to make it public.
Saved data. Each user gets their own isolated data, plus shared data for the whole app, with nothing to configure.
Region-pinned storage. Your data stays in Australia or the US, your choice, and never crosses between them.

Why there’s no AI inside the app

This is the part people don’t expect: once it’s live, your Backlit app has no AI running inside it. The intelligence happened while you built it. The running app is plain, predictable HTML backed by storage and sign-in.

That’s deliberate. A chore chart doesn’t need a chatbot. Keeping AI out of the running app is what makes it fast, private, predictable, and cheap: a couple of dollars a month, not a per-visit AI bill. Backlit is plumbing, not a co-pilot.

When Backlit isn’t the right tool

Backlit is for single-page apps, the kind AI hands you as one file. If you’re building a large, multi-file application with its own build pipeline, or something that genuinely needs a server runtime or AI processing on every request, you want a different tool. Backlit is for the enormous category of small, useful apps that just need to get off your screen and into other people’s hands.

The takeaway

If you built it with Claude and you’re staring at an app that only works for you, you don’t need to learn hosting, auth, or databases. Connect Backlit, ask Claude to publish it, and share the link. That’s the whole thing. From vibe to live.

Built an app with Claude or ChatGPT? Get early access to Backlit and share it in seconds.