Small software: the apps between a spreadsheet and a SaaS

There is a whole category of software that almost never gets built. Not because it is hard. Because it is the wrong size.

It is too big for a spreadsheet. The spreadsheet works right up until two people edit the same row, or you need someone to approve something, or you want an email to go out when a value changes. It is too small to buy, because no SaaS product is shaped exactly like your team, and the ones that are close do 10% of what you need and charge per seat for it. And it is too small to build the normal way, because standing up auth plus a database plus hosting for a 200-line app is a week of plumbing nobody has time for.

That in-between category is small software. It is real, every team has a pile of it, and until recently there was nowhere good to put it.

What small software actually looks like

You already know these tools. Your team has wished for most of them.

• An expense request that a manager approves before finance pays it.
• A signature request: send a document, collect a name and a timestamp, log who signed and when.
• An on-call rotation that knows who has the pager this week.
• A customer-feedback board where people file an idea and others upvote it.
• An internal request form that routes to the right person and pings them.
• A team directory that is actually current, because people edit their own row.

None of these is a hard problem. Each is a couple hundred lines of code and a database table or two. What makes them hard is everything that is not the app: who is allowed to open it, where the data lives, how it goes out to the team.

Why it never gets built

Look at what shipping one of these the ordinary way costs.

You provision a server. You add authentication so only your coworkers get in. You add a database and figure out migrations. You wire up email. You deploy it, get a URL, and then you own keeping it alive and patched forever. That is a week of work wrapped around an afternoon of app.

So the tool does not ship. The team bends a spreadsheet until it breaks. Or pays for a SaaS that is close-ish and eats a per-seat budget line. Or files a ticket with engineering and waits a quarter for something that was never on the roadmap. This is the failure mode of every internal tool: the work was never the bottleneck. The infrastructure around the work was.

The economics only work with a small cloud

Small software needs somewhere to run that was built for it. That place is a small cloud: a platform where auth, a database, file storage, scheduled jobs, email, and secrets are already there. You do not provision anything. You write the app and the cloud runs it.

On fuast the app is a capsule: one small full-stack TypeScript file set with a server/ half and a client/ half. You import fuast/server, describe a schema, add a few functions, and that is a working backend with a real database and verified sign-in.

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 the whole trick. The week of plumbing collapses to an import. When the plumbing is free, an afternoon of app is worth building, and small software stops being a graveyard of half-finished spreadsheets.

Why the category is showing up now

Two things changed at once. The batteries got bundled, so the infrastructure around the app is included instead of assembled. And your AI can now write the app itself. A cloud that is agent-native publishes its whole contract in one file at /llms.txt, so you can say "build us a discount-approval tool" and an AI writes the capsule for you. You run one command to deploy it.

The AI is good at the app. The small cloud is good at everything around the app. Neither was true two years ago. Both are true now, which is exactly why small software is finally getting built instead of wished for. If you want the deeper version of the platform side, read what is a small cloud.

Your team has its own pile of small software it keeps meaning to build. Pick one and ship it this afternoon.