Why AirState Must Exists

We believe that features that 10x the value (and thereby growth) of a product often don't ship early enough because of the complexities involved in building and maintain the supporting infrastructure for these features.

AirState builds infrastructure that reduces this complexity and makes the choice obvious: Of course you ship the feature that multiplies value while the primary focus of your engineering time remains solving real business problems.

By integrating AirState's SDKs you no longer have to choose between solving problems and focusing on growth.

Our internal tagline is "Over-the-air solutions for the roughest edges around building truly valuable software."

－ Omran Jamal, CEO, AirState

There are two things that came up time and again in the 11 years we (the founders) have been building software. We never quite found a great generic solution to these. While different in use-case, they are surprisingly similar in underlying implementation.

1. Real-time Syncing
2. Real-time Collaboration

These are the rough edges we (currently) are solving for.

The modern world is simply too busy to be waiting and re-checking. Not forcing your users to refresh the page when changes happen on the backend or in a far-away place in the real-world is simply the table stakes for building software for the modern world.

Every user beings in 10 more once you start providing Figma level real-time mirroring or following features, or Miro level real-time collaboration. It is no surprise that Pitch.com's stickiest feature shipped in recent times has been the ability to add multiple presenters when pitching.

Once you have users bring in their colleagues, it's near impossible to choose another tool.

The request-response cycle is dead. Apps, especially AI apps, no longer fit neatly into the synchronous nature of the request-response cycle. Materializing each response through the mesh of queues, AI inference servers, long running processes may take up to several minutes in the worst case.

Now it is the servers that must update the client in real-time. Not the other way round anymore.

Nothing makes a product stickier than network effects, and the best approach to building a network over a SaaS product is enabling collaboration.

Work rarely happens in a vacuum alone; no one rejects an invite to collaborate on a piece of work they were already doing.

You either build (real-time) collaboration, or lose customers to products which do implement collaboration.

Every time you think of a well executed real-time collaboration experience, you probably think: Notion, Figma, Miro, Mural, Linear, Monday.com, Greenhouse, Databricks － all platforms that are unicorns (or very close) and has extensive real-time collaboration support.

Either

• Real-time itself is a moat that drives down their churn and boosts their valuation.
• Real-time is hard to execute and only the largest companies can afford to build it.

We think it's both, simultaneously.

It takes on average around 12 engineering-months (4 engineers, 3 months) to launch the first version of a collaboration feature. In fact, it took Figma a year to build and release real-time collaboration.

Of course WebSockets, WebRTC, SSE, and even (long)polling has basically existed forever. These are the new Layer 0 of the networking stack as these are still message based protocols.

Usually, building systems that convert messages into high level real-time collaboration features requires specific engineering skill-sets in the team. Skills that are adjacent to distributed systems and network programming. Engineering teams are left to build (offline-)syncing, conflict resolution, presence & awareness by themselves.

This rarely makes sense for engineering leadership to make these kinds of time and energy investments when building the first version of the first real-time collaboration or real-time syncing feature. When you have an already established product, it's often feels like maneuvering a cargo ship to avoid a seagull.

It's no doubt that serverless is now the default way to ship software. Same same technology that simultaneously made our apps blazing fast and surprisingly cost-effective to scale is inherently incompatible with the requirements of real-time.

Serverless was designed for the request-response era but the core of real-time updates and syncing is persistent connections between client and server. Supporting WebSockets or SSE on serverless infra is a recipe for runaway cloud bills.

The usual choice to reach for when solving these challenges is either a frontend database that syncs to the backend, like ElectricSQL or LiveStore, or a full fledged backend-as-a-service like Firebase or Supabase.

Sadly, you'll rarely see "serious" companies beyond Series A still banking on these technologies.

These are amazing pieces of technology. They are also very new. Engineering teams going this route are introduced with three very important reality-checks.

1. You are asked to re-think and re-architect how you build your apps to the mental models brought in by the database.
2. Your choice in backend stacks (especially when it comes to the database) is suddenly dictated by the frontend.
3. Building and security models for this new method of work is starkly different (and often more complex) when frontend can read and write freely.

Another amazing piece of technology that revolutionized mobile apps once upon a time. The realities are a bit different from yet very to frontend databases.

1. You are asked to bypass your backend entirely.
2. Maintaining security is even harder.
3. Often you are building apps from the ground up to fit the BaaS's mental model.
4. Unpredictable scaling characteristics; unforeseen limitations.

In our conversations with engineering leadership across various companies at different stages (up to ones that are raising series D), we've noticed one common pattern: choosing open-source over proprietary technology isn't about cost. In-fact it's rarely about cost if technologies are priced fairly.

Choosing open-source is more about longevity and self-reliance. Nothing worse than building an app on a platform that might not exist tomorrow, or worse, building a product on a technology that might not serve you well just as you start to scale.

Open-source would mean you and your team are fully aware of the capabilities of technologies you introduce into your stack, and even if you use a cloud-hosted version of the technology, there is always a solid off-boarding story via self-hosting.

AirState is us building out our vision of a internet that is more magical, collaborative and realtime while allowing engineers to continue standing on the shoulder of giants.

AirState builds and maintains ServerState. Irrespective of is the client is connected to it or not, a server, a queue worker, or a short-lived serverless execution can push data to the client in real-time.

When using AirState, engineers model their state and mutations to that state. Much like how modern UIs are built.

AirState's SDKs handle message passing under the hood using WebSockets so that engineers aren't thinking about individual messages and how they culminate into a macroscopic feature.

Engineering teams and their leadership should not be choosing between features that solve problems and features that drive growth.

AirState's SDKs are built from day one to be easiest way to integrate real-time collaboration without introducing any of the risks involved with introducing hard to integrate proprietary technologies.

At AirState we try to make sure that our SDKs and approach never asks your engineering team to re-think your stack or change the way you build apps in any significant way.

We optimize to be the perfect add-on to existing apps, their stacks and their engineering processes.

Our AirState server itself is built in GoLang, NodeJS and extensively utilizes open-source libraries. There's no secret sauce, we just build it so you don't have to.

We distribute AirState server as a Docker image that anyone can start with a connection to a Redis Valkey cluster and a NATS cluster.

The commercial for-profit endeavors of AirState is all about abstracting away the ops part of building, scaling and maintenance of real-time infrastructure.

We know devops is hard. We also know devops teams are already overburdened with the business end of the apps we build.

AirState (the company) uses exact same version of AirState Server in our cloud as the open source version. The cost-efficiency comes from economies of scale, as our 6 availability regions across the continents are over-allocation of memory and CPU can be shared between all our customers across the globe.

We are in fact raising our pre-seed round.

Checkout our Deck, or get in touch with the founders:

• omran@airstate.dev (CEO)
• tanvir@airstate.dev (CTO)
• samiha@airstate.dev (CGO)

You need to add real-time syncing and collaboration to it. Trust us.

Read the Docs or Signup to AirState Cloud