AI has shredded so many barriers to building: with the novelty of capable coding agents, we started to see a rapid expansion of internal apps and prototypes. We wanted anyone on the team to be able to build an app that could use internal data, connect to an LLM, and be shared securely.
That was the vision for Zeus. We just crossed more than 500 internal apps & prototypes running on the platform, which is ~3x the headcount of our engineering, product and design org.
Some Zeus apps are universally used and will get their own blog posts in the future, like our internal coding agent, Forge.
The PLG team built the PLG HQ, which drops confetti on demo day and gives everyone a bear to control.
The design team made an app for brand assets:
We all needed the Owner Atlas app, so we could search for food near us:
And one person really needed to go back to '95:
How it works
We built Zeus to solve 4 problems.
First problem: internal apps were being deployed in all kinds of ways. Before Zeus, new internal apps were appearing constantly with different hosts, databases, and vendors. We wanted one frontend system, with everything deployed in the same place with the same database setup. With Zeus you click “generate app,” and a minute later you have a web app (Tanstack Start or Astro, react, server-side rendering, file-based routing). Zeus makes a GitHub repo, provisions a Postgres database and a storage bucket, scaffolds the template into the repo, injects the secrets, and commits. GitHub Actions deploys it, and Zeus watches to make sure the first deployment completes.
All apps run on Cloudflare's Workers for Platforms. They share one namespace, and a single gateway worker sits in front and routes each request to the right app. This gives us room for 10,000 apps before the next limit. Everything lives under one domain, and each app is a subdomain of owner.sh.
2nd problem: giving every app safe access to our data.
Zeus gives every app built-in access to our systems and holds the credentials itself without a vendor key. It calls a Zeus proxy, and Zeus handles auth, rotation, and logging. Out of the box, an app can:
- Query Snowflake. One click mints a key, and the app queries through our Snowflake proxy. The app holds no Snowflake credentials of its own.
- Call an LLM. Every app routes AI calls through Poros, our internal inference router. We track cost per app, swap models, and fail over between vendors.
- Post to Slack. Flip on the integration and the app sends messages under its own name and avatar.
- Send email. A shared services worker sends email to owner.com addresses, so apps don’t each set up a mailer.
- Run scheduled jobs. A central scheduler triggers each app’s cron handler on time.
3rd problem: auth, app permissions and security. Auth runs through Shibboleth, our sign-in portal. It uses our Okta SSO, lets in only owner.com accounts, and is completely separate from our production product auth. The gateway worker checks auth on every request before it reaches an app for extra security. If you're not signed in, it sends you to Shibboleth first.
Permissions are per app. An app is either open to anyone at the company or limited to people you grant in. Each grant carries a role, member or admin. You can bundle users into a group and grant the group across several apps. You manage all of it from the app’s page. Apps you share company-wide show up in the gallery.
4th problem: we needed to be able to update all the apps agentically as we make updates in the future. Our migrations system creates an isolated session on a throwaway VM for each app. The agent clones the app, makes the change, and opens a single PR. A manager session reviews all the PRs, retriggers updates when needed, and merges updates. We use this to bump dependencies, patch vulnerabilities, and roll out shared changes/upgrades. We can also run a read-only version that just reports back for compliance or tracking purposes.
All app logs drain into Datadog so users can debug their apps and the company has visibility into what's running. Zeus has a CLI for developers to manage and debug their apps.
The result is that when you plug your AI coding tool into a Zeus app, it doesn’t need to ask you configuration questions that you may or may not be able to answer. Auth, database, deployment, CI, monitoring, environment. That’s all decided. You just describe what you want to build.
100% adoption
App growth has been steadily increasing since the early days of the Zeus launch. Our teams can just ship apps instead of spending time evaluating tools and onboarding to new services, with just a few exceptions. Adoption across our team has been pretty organic since it’s so quick and painless to get started on the platform.
Every assumption we made about how small this would stay was wrong. And maybe this connects to where things are generally headed: the boundaries between engineering, design, and product are blurring. More people default to building. They see a problem and now have the tools to go do something about it. It used to require getting an engineer’s time, getting approval, getting API keys, getting access to systems. Zeus removes all of that.
A few things we learned
The first version was way too ambitious and overcomplicated.
We tried to build our own system for deployments and CI, basically bypassing GitHub Actions. Users would push code directly into Zeus for processing. Presumably this would let us analyze code and add security guardrails. But that ended up being too restrictive for all the edge-cases of what people wanted to build. We scrapped it and went with the generator approach we have now, in which Zeus scaffolds a real repo with real CI and gets out of your way.
At first, we didn't plan for how fast it would grow.
We were limited by how many workers we could deploy on one account. When we started, we barely thought about it, figuring it’d be a long time before we hit the limit. Then we passed 100 apps, and it became clear we’d blow through that limit quickly. That forced a migration to Workers for Platforms while also keeping all the existing standalone workers running.
We needed a way to maintain hundreds, maybe thousands, of apps.
The obvious risk with a platform like this is that apps get built, deliver some value, and then get forgotten. With 500+ apps and no guarantee each one has a long-term owner, that’s a problem. We built the migrations system where we can write a prompt for an AI agent and run it against every app on the platform at once. The apps don’t rot because the platform itself maintains them to a minimum standard.
Expectations and needed features grew quickly
Zeus began on a pure whim, and very much a side project to day-to-day responsibilities at Owner. Within a few short months, HR and finance built apps with highly sensitive data. A few apps were built that eclipsed the capacity of our original SQLite databases, and some of our builders clamored for dedicated compute features. Luckily, Owner has a supportive organization and we’ve managed to scale Zeus with contributions from VP Eng (thanks Max!) and now a second dedicated team member, Lucas.
If you’re going to build this for your team:
You can’t predict what people will build. You can’t predict how complex the apps will be. You can’t predict the volume of apps. People will build more complex apps than you expect. They will build more apps than you expect. They’ll build single-purpose apps that will be used once in a meeting to make a decision, and then never again. They’ll build apps that become a key part of every demo and sales call we do across the company every day.
Everything that used to be impossible can now be built, and this means people will also build buggy slop, or accidentally extend beyond key boundaries. For better or worse, it’s an arms race between the platform and the builders. Don’t underestimate someone’s crazy off-the-rails agent.
As a starting point, pick the batteries that matter. For us, this was auth, hosting, and databases. That’s what people were repeatedly getting stuck on. If we’d tried to ship 30 different platform features on day 1, it probably would’ve been too complicated and nobody would have used it. Start with what people are already struggling with.
Thanks for reading
Building Zeus has been a blast, and a great learning experience. For better or worse, our industry has completely changed. As builders, we need to ensure we embrace AI tools and new ways of working, and I believe that we can use them as a force for good for our mission, customers, and team. I’m grateful to Owner for the trust to build aggressively, explore the frontier, and to continue scaling what we’ve found works. Hopefully this can inspire others to get out there and build.