fuast is in alpha. Read the capsule contract →
fuast
← Blog
ConceptJuly 31, 2026

What is a small cloud? And why your team keeps needing one

A small cloud runs the little apps that live between a spreadsheet and a real SaaS product. Here is what that means, and why the gap has stayed open for so long.


Every team has a graveyard of half-built tools. A spreadsheet with six tabs and a macro nobody understands. A Slack channel that is pretending to be an approval queue. A Notion page that is pretending to be a database. They all exist because someone needed a small piece of software, and the options for getting it were all bad.

That gap has a name now: small software. And small software needs somewhere to run. That is what a small cloud is.

The gap between a spreadsheet and a SaaS

Think about the last internal tool your team wished for. Maybe it was an expense approval flow. Maybe a way for the sales team to request a discount and have finance sign off. Maybe just a form that logs a request and emails the right person.

None of those are hard problems. Any of them is a couple hundred lines of code. But look at what it actually takes to ship one the normal way:

  • Stand up a server somewhere.
  • Add authentication so only your coworkers can use it.
  • Add a database and a way to run migrations.
  • Add file storage if it touches uploads.
  • Wire up a way to send email.
  • Deploy it, get a URL, keep it running, keep it patched.

That is a week of plumbing for an afternoon of app. So the tool never gets built. The team bends a spreadsheet until it breaks, or pays for a SaaS product that does 10% of what they need and charges per seat for the privilege, or files a ticket with engineering and waits a quarter.

The work was never the hard part. The infrastructure around the work was.

A small cloud is the infrastructure, already assembled

A small cloud flips the ratio. Instead of a blank server you have to configure, you get a platform where auth, a database, file storage, scheduled jobs, email, and secrets are already there. You write the app; the cloud runs it and handles the rest.

On fuast that app is a capsule: one small full-stack TypeScript file set. You import fuast/server, define a schema and a few functions, and you are done. No npm install, no Dockerfile, no cloud console.

import { capsule, table, string, mutation, query } from "fuast/server";

export default capsule({
  schema: {
    requests: table({ what: string(), by: string(), status: string() }),
  },
  queries: {
    all: query(async (ctx) => ctx.db.requests.order("desc").collect()),
  },
  mutations: {
    submit: mutation(async (ctx, what: string) => {
      if (ctx.auth.isGuest) throw new Error("sign in first");
      return ctx.db.requests.insert({ what, by: ctx.auth.userId, status: "pending" });
    }),
  },
});

That is a working backend with a real database and verified sign-in. The batteries are included because a small cloud is scoped to small software on purpose. It is not trying to run your whole company. It is trying to make the fifty-line app trivial.

Why now: your AI can write the app

The gap stayed open for years because even an afternoon of app is more than a busy ops person or founder will do between meetings. What changed is that you no longer have to write it yourself.

A small cloud that is agent-native publishes its entire contract in one file so an AI can read it and build to it. On fuast that file is /llms.txt. You tell your AI "build us a discount-approval tool where sales submits and finance signs off," it writes the capsule, and you run one command to deploy it.

The AI is good at the app. The cloud is good at everything around the app. Neither of those was true two years ago. Both are true now, which is exactly why the small cloud is showing up now.

The last mile: sharing

Building the tool is only half of it. The other half is getting it to your team, and this is where most approaches fall down. A prototype from an AI app builder lives on your laptop. A script lives in a repo only engineers can run.

A small cloud closes that mile by making software share like a doc. You deploy, you get a link, you send it. Coworkers open the link, sign in with their own account, and the app sees who they are. Private to you, shared with the workspace, or public. It is the same motion as sharing a Google Doc, and it is the thing that turns "I built a tool" into "the team uses a tool."

So, what is a small cloud?

It is the place small software runs. Batteries included so you write the app and nothing else. Agent-native so your AI can write it. Shareable so your team actually uses it. The plumbing that used to eat a week is just there, and the app that used to never get built gets built this afternoon.

If your team has its own graveyard of half-built tools, that is the gap talking. Try building one for real.

Build one this afternoon.

Tell your AI what your team needs. fuast runs it and signs everyone in.

Start free

Keep reading