Share software like a doc: the missing primitive for team tools

Building the tool is half the job. The half everyone forgets is the last mile: actually getting your team onto it. That gap is where most internal tools die, and it is the part that a small cloud has to solve or nothing else matters.

The last-mile problem

Say you built the thing. An expense approval, a feedback board, a request form. It works on your machine. Now what?

This is where it usually stalls. A prototype from an AI builder lives on your laptop and cannot be sent anywhere. A script lives in a repo only engineers can clone and run. A "real" deploy means you now have to answer a pile of questions that have nothing to do with the app: where does it run, who is allowed in, how do people sign in, how do you keep a stranger from opening it. Each of those is a project. Stack them up and the tool that took an afternoon takes a month to get into anyone's hands, so it never does.

The work was done. The distribution was not. That is the last mile, and it is where good small software goes to die.

The primitive that fixes it: share like a doc

Think about how you share a Google Doc. You do not provision a viewer server. You do not build a login page. You click share, you get a link, you send it. The person who opens it signs in as themselves, and the doc knows who they are. Comments have names on them because identity came for free.

Software should work the same way, and on fuast it does. This is share like a doc, and it is one motion:

• You fuast deploy and get a link.
• You send the link to your coworkers.
• They open it and sign in with their own account.
• The app sees a verified identity for each of them.

No login page to build. No user table to manage. No invite system to design. The same gesture that shares a document shares a working app.

Verified identity is the whole point

The reason this matters beyond convenience is what the app gets on the other side. When a coworker opens your tool, the capsule sees a real, platform-verified user. In the server code that is ctx.auth: a userId, and an email and display name, that fuast vouched for. Your code never asks who someone is, and it never trusts the client to say.

submitExpense: mutation(async (ctx, amount: number) => {
  if (ctx.auth.isGuest) throw new Error("sign in first");
  return ctx.db.expenses.insert({
    amount,
    submittedBy: ctx.auth.userId,   // verified, not passed in
    status: "pending",
  });
}),

That one line, submittedBy: ctx.auth.userId, is what a built login page usually takes a week to earn. Because identity is verified upstream, your approval flow actually knows who approved. Your feedback board knows who upvoted. Your directory lets people edit their own row and nobody else's. The tool is trustworthy because the identity is real.

Private, workspace, or public

Sharing is not all-or-nothing. Every app has a visibility, and you set it with one command.

• Private. Only you can open it. This is the default, so a fresh deploy is never accidentally exposed.
• Workspace. Anyone in your workspace, your team on fuast, can open it after they sign in. This is the common case for an internal tool.
• Public. Anyone with the link can open it, useful for a feedback board or an intake form where guests should get in.

fuast share my-app --visibility workspace

People you invite by email join the workspace when they accept, so growing the circle is just sending a link. The scope of who can see a tool is a property you set, not infrastructure you build.

Why this is a primitive, not a feature

It is tempting to file "sharing" under nice-to-have. It is the opposite. Sharing is the thing that turns "I built a tool" into "the team uses a tool," and everything else, the AI writing the capsule, the batteries being included, is in service of getting to a link your coworkers can open.

A small cloud that made building trivial but left distribution as your problem would have solved the easy half. Sharing like a doc solves the half that actually blocked you.

Build the tool your team keeps asking for, send them the link, and watch them sign in. Start here.