Y Combinator's Fall 2026 Requests for Startups includes an entry by Pete Koomen called "A Cloud for Small Software," and it gives a name to something that has been growing underneath the industry for years:
"Using agents to build personal software to solve your own problems is a lot of fun. This is 'Small Software'. Purpose-built tools that will only ever have one or a small handful of users. [...] Software like this is now very easy to build, but still hard to deploy and share. Incumbent clouds like Azure and AWS were designed for shipping Big Software that scales with many users... at the cost of complexity."
We have skin in this game: Miget is a flat-rate cloud we have been building since November 2023 for exactly this class of software, so read what follows with that disclosure in mind. But precisely because we have spent three years in this problem, we can do something more useful than cheer: lay out what a cloud for small software actually requires, and be honest about which of those requirements are solved, by us or anyone.
What small software is
The RFS defines it precisely: purpose-built tools that will only ever have one or a small handful of users. Concretely, that is:
- The script that became a dashboard that became the tool your whole team checks every morning.
- The client portal you built for one customer, and then for another one.
- The internal CRUD app that replaced a spreadsheet, with a database behind it because the spreadsheet started corrupting.
- The Streamlit data app, the n8n workflow, the Slack bot, the webhook glue.
- And, increasingly, the app an agent wrote this afternoon - the Lovable export, the Claude-generated tool, the thing that did not exist at breakfast.
Small software was always the majority of software by count. What changed is the production rate: agents collapsed the cost of writing it, so the bottleneck moved to the next step in the chain. As the RFS puts it, this software is "very easy to build, but still hard to deploy and share."
Why the big clouds fail it
Not because they are bad - because they are calibrated for the opposite problem. AWS and Azure are built for Big Software: one application, many users, a team of engineers amortizing the complexity. Small software inverts every one of those ratios: many applications, few users each, often one person and zero patience for infrastructure.
Two specific failures follow:
The complexity tax is charged per app. A VPC, IAM roles, a deployment pipeline, TLS, monitoring - Big Software pays this once and amortizes it over a million users. Small software pays it for every single tool. Ten small apps on a big cloud is ten sets of ceremony, which is why most small software never gets deployed at all and dies as a script on someone's laptop.
The billing model is charged per app too. Usage meters and per-service pricing mean every additional tool is an additional line item, an additional thing that can surprise you on an invoice. We wrote a whole analysis of the pricing models and the conclusion bears repeating: when the marginal cost of one more app is a new bill, people ration apps. Rationing is death for small software, whose entire value is that there can be lots of it.
What a cloud for small software must do
Having built one, argued with it, and run other people's workloads on it for three years, this is our list of requirements. The first four are engineering; the fifth is the frontier.
1. Deploy from whatever exists. Small software arrives in whatever shape it was born: a repo with a package.json, a Dockerfile, a docker-compose.yml an agent generated. A cloud for small software takes all of them without a config file of its own. This is solvable and solved - buildpacks detect the stack, compose files describe multi-service tools, and a git push is the whole pipeline.
2. Make the marginal app free. The unit of pricing has to be capacity, not applications - a plan you fill with as many tools as fit, where the eleventh app costs nothing beyond the RAM it uses. This is the single highest-leverage design decision, because it changes user behavior: people stop asking "is this tool worth a bill?" and just deploy it.
3. Include the boring dependencies. Nearly every small tool wants a Postgres, a cache, maybe a queue. If those are separate metered products, every small app quietly becomes three bills and an integration project. They have to be in the box, at no extra cost, or the complexity the RFS wants deleted just reappears wearing a database costume.
4. Isolate like the code is hostile, because it might be. This is the requirement people underestimate. The RFS names it directly: "allowing nontechnical users to share arbitrary code is tricky to do securely." Small software is, increasingly, code that no human reviewed - written by an agent, deployed by a person who could not audit it if they wanted to. Namespace-grade container isolation is not an acceptable answer when thousands of unreviewed tools from different tenants share kernels. This is why we run every workload in its own MicroVM with a hardware boundary, and why we consider that a requirement of the category, not a feature of ours.
5. Make sharing as easy as a Google Doc. The RFS sets this bar explicitly, and it is the right bar: "Small software should be as easy to share with your colleagues as a Google Doc." That means a link, per-person permissions, revocation, and no "first, create an account and read about deployments" for the recipient.
The honest scorecard
Where this actually stands, for us and for the category:
Requirements one through four exist today. On Miget you deploy from git, Dockerfile, or compose; a flat plan holds unlimited apps; PostgreSQL, MySQL, Valkey, RabbitMQ and Kafka are included at $0; and every workload gets its own MicroVM. We did not build these because we read the RFS last week - the RFS describes them because they are what this class of software forces you to conclude. Our catalogue of 140 ready-to-deploy stacks exists for the same reason: most small software wants the same twenty backing services, pre-shaped.
Requirement five is not solved - not by us, and we would argue not by anyone yet. We have pieces of it: workspaces with role-based access, preview environments per branch, TLS on a real URL for every app. But "as easy as a Google Doc" is a genuinely high bar. A Google Doc share takes four seconds, works for your least technical colleague, and carries permissions with it. No infrastructure product today passes that test for arbitrary running software, ours included. The RFS is right to call out auth and permissions as hard rather than waving at them - identity for small software gets strange quickly, especially once some of the "colleagues" are agents with their own credentials.
That is the honest state of the category: the compute problem is solved, the economics problem is solved, the isolation problem is solved by the platforms that took it seriously, and the sharing problem is where the next few years of work are.
Why this moment
The RFS ends by noting that a cloud like this "could delete most of this complexity and unlock a big set of new use cases that agents have only recently made possible." That is the part worth sitting with. Every previous generation of small software was capped by the number of people who could write it. This one is not. The tools are being written regardless - by developers at lunch, by analysts with an agent, by builders exporting from Lovable - and each one needs somewhere cheap, boring, and safe to live.
We think the answer looks like a flat plan full of MicroVMs with the databases included. YC is now asking who else thinks so, and honestly: good. Categories get real when more than one company takes them seriously.
Frequently asked questions
What is "small software"?
The term, as used in Y Combinator's Fall 2026 RFS, means purpose-built tools that will only ever have one or a small handful of users: personal utilities, internal team tools, bespoke workflow apps, client-specific portals. It is now very easy to create - increasingly by AI agents - but still disproportionately hard to deploy and share.
Why not just use AWS or Azure for small tools?
Because their complexity and their billing are both calibrated for large applications. Every small app on a big cloud pays the full ceremony (networking, IAM, pipelines, TLS) and becomes its own set of line items. The cost is not the compute, it is the overhead per application - and small software's defining property is that there are many applications.
What should a cloud for small software provide?
Deployment from whatever shape the code already has (repo, Dockerfile, compose file); pricing where additional apps inside a plan cost nothing; databases and queues included rather than metered separately; strong per-workload isolation, because much of this code is unreviewed; and sharing with link-plus-permissions simplicity. The first four exist today; the fifth is the open frontier.
Is Miget a cloud for small software?
It is our attempt at one, three years in: flat-rate plans holding unlimited apps, deploys from git, Docker, or compose, managed databases included at $0, and every workload in its own MicroVM. The sharing experience the RFS describes - as easy as a Google Doc - is the part we, like everyone, have not fully built yet, and we say so above.
Does small software need real isolation?
More than big software does, arguably. Big Software is reviewed, audited, and deployed by professionals. Small software is increasingly written by agents and deployed by people who never read it. Running thousands of such tools from different owners on shared kernels is how incidents happen; hardware-boundary isolation per workload is the honest baseline for this category.