Blog

How to give a coworker access to an app you built with AI, and nobody else

The tool is finished and one person needs to use it with you. What "only my coworker can open it" really requires, what they see when you invite them, what happens if someone else finds the link, and how to take access away.

You built a small tool with a coding agent: a checklist, a tracker, a place to log requests. It is for you and one or two people you work with, and it holds things that shouldn't be public: client names, prices, who owes what.

So the request is narrow. Not "put it on the internet". It is "let Sam use this with me, and nobody else".

This article is about that request: what it takes, what your coworker sees, and how to change your mind later. We make Spryloom, so the last part describes our version. For the wider question of where to run the app at all, see How to share a Claude Code app with your team, which compares the options fairly.

"Only my coworker" is three things

  1. The app knows who is asking. Every visit has to arrive with a name attached, and the name has to be checked, not typed into a box by whoever is visiting.
  2. A list of who is allowed. You, and the people you named. Everyone else is turned away, including someone who was forwarded the link.
  3. A way to change the list. People join a project and leave it. Removing someone has to work straight away, not when their session happens to run out.

A link nobody knows about is none of these. Links get pasted into chats, forwarded, saved in browser history and shown on shared screens. If the app opens for anyone who has the address, it is public, just quiet about it.

Why "add a login" is harder than it sounds

The natural thing is to ask your agent to add a login. It will: a sign-in page, sessions, password resets or email links, a table of users. Now your small tool has the most sensitive code in it, written in one afternoon, and that code has to stay correct every time the agent changes something else.

The other route is to keep sign-in out of the app entirely and put it in front: something checks who you are before the request reaches the app at all. Companies do this with products like Cloudflare Access or an identity-aware proxy. It is the safer design, and it usually needs someone comfortable configuring it.

What it looks like with Spryloom

Spryloom runs apps for teams behind sign-in, with that check in front of the app rather than inside it. The app itself contains no login code.

When your agent publishes the app, it asks one question about access:

Who should be able to use it?
  1. Just you
  2. People you invite
  3. Anyone at <your company's domain>

Choose the second. Then invite your coworker, by asking the agent ("invite sam@yourcompany.com") or from a terminal:

spry invite my-app --email sam@yourcompany.com

What Sam sees

Sam gets an email that names the app, says who invited them and what the app does, in the words you or your agent wrote when publishing. It has one Open button. Clicking it signs Sam in straight away: no account to create, no password, nothing to install. The button works once, for seven days. After that, Sam opens the app's address and asks for a sign-in link, which arrives by email.

Inside the app, Sam is Sam. The app is told who each visitor is, so it can show "added by Sam" next to an item or send Sam a reminder, without asking anyone to type their name.

What everyone else sees

Someone who opens the address without being invited reaches the sign-in page, asks for a link, and nothing arrives. The page never says whether their address is on the list, so it gives nothing away. It does tell them what to do: ask whoever shared the app to invite them.

Someone signed in with a different account is told they don't have access, and who to ask.

Taking access away

spry uninvite my-app --email sam@yourcompany.com

This works on Sam's next click, not when a session expires. Being let into one app also grants nothing on any other app, even in the same workspace.

You stay in charge of your own app whatever you change: the owner and the admins listed in the app can always open it.

Choosing the other options

  • Just you is the default for a new app, and right while it is half-finished.
  • Anyone at your company's domain suits a tool the whole company uses: anyone who signs in with an address at that domain gets in. It needs you to have signed in with your work address. With a personal address such as Gmail, invite people by name instead.

What it doesn't do

  • It is for people you know. Everyone who uses the app signs in. A public website or a product for customers belongs on a normal host.
  • Sign-in is by an emailed link, for everyone. There are no passwords, and no separate accounts to manage.
  • Roles are owner, admin and user. Finer permissions inside the app, such as "Sam can view but not edit", are the app's own logic. Your agent can write them, using the name Spryloom passes to the app.

Start here

In Claude Code, add the plugin once:

/plugin marketplace add spryloom/claude-plugin
/plugin install spryloom@spryloom

Then say "publish this with Spryloom, and invite sam@yourcompany.com". Without the plugin, from the app's folder:

npx -y spryloom publish

Before you send anyone the link, open it in a private browser window, where you are signed in to nothing. You should see a sign-in page, not your app.

Spryloom publishes apps and pages built with a coding agent behind sign-in, for the people you invite. This article was written by the people building it.

Get started free