In development · First version September 2026

The cloud for small software.

Deploy the tools you build in one step, and share them like documents — with identity, permissions, and per-user data already handled.

The gap

The software is free. Everything around it isn't.

A shift rota for a restaurant. A pipeline tracker for two salespeople. A dashboard that exists because someone needed it on a Tuesday. Agents made all of it nearly free to write — and changed nothing about what comes next.

Getting it to your team today

  • Provision a container and a runtime
  • Stand up a database and connect it
  • Wire up an auth provider
  • Write a permissions model by hand
  • Buy a domain, configure DNS and TLS

An afternoon — for a tool with four users.

Getting it to your team on SwarmGen

  • Build on a foundation that already handles it
  • Deploy to a live URL in one step
  • Send someone the link

Their access is already correct.

What the platform owns

The parts you shouldn't be writing.

Identity, isolation, and who-sees-what belong to the cloud underneath — not to the app on top of it, and not to whoever or whatever wrote that app.

Identity, not integration

Every app knows who its users are the moment it exists. No provider to choose, no callback URLs, no login screen to build.

Sharing by link

Send someone a URL and they have exactly the access they should have. Sharing a tool should be no harder than sharing a document.

Data that scopes itself

Each user sees their own correct slice of shared data, kept live as it changes — decided by the platform rather than by hand-written checks.

The part everyone underestimates

Hosting isn't the hard part. Anyone can run a container.

The hard part arrives the moment a second person opens your app.

Two people open the same shift rota. The manager should see every shift; each server should see only their own. Then someone swaps a Tuesday — and both screens have to change, without either person seeing a row they were never meant to.

That isn't a feature you bolt on at the end. It's a question the app has to answer for every user, on every change, forever. And on every existing platform, answering it is handed back to the developer — which is precisely the person who no longer exists when the app was written by describing it.

How it works

State a rule once. It stays true everywhere.

One rule, stated once
Recomputed in memory
Reflected on screen
Persisted to the database
Live on every other user's screen

Change a value and everything derived from it updates — locally, and for everyone whose view depends on it.

Why me

I spent a decade solving this before it had a market.

Adrian Pinter

Founder · Kyoto, Japan

I built a multilingual point-of-sale system and, underneath it, a framework where a rule is stated once as a declarative expression and stays true everywhere — recomputed in memory, reflected in the UI, persisted to the database, and propagated live to every other user whose view depends on it.

Reactive properties for the rules. A patch format designed for object models rather than plain JSON. Query filters deciding what each user is entitled to see at all. It shipped, and it ran a real business for years.

SwarmGen is that mechanism, turned into a cloud.

Reactive properties Entity JSON Patch Query filters Live multi-user sync Read the technical write-up →

Hit this wall yourself?

SwarmGen is early, so there's nothing to sign up for yet. But if you've built something small and useful and then couldn't get it to the people who needed it, tell me where it broke down. I read and answer every message myself, and what people send me decides what gets built first.

adrian@chainreact.net