AI has made building internal apps inexpensive, but deployment, authentication, hosting, and sharing still block non-engineers.
2
WorkOS gives every employee the WOW CLI, which prepares a repository and development tools, then deploys apps through the Atlas platform.
3
WorkOS has 278 apps in its registry, more than 3 million weekly requests, and 37% of regularly used apps were built without an engineer in any commit.
Summary
Garrett Galow describes how WorkOS moved internal app development beyond the build step. He begins with Perona GPT, a sales chatbot built by an account executive before maternity leave. The CEO could not open it because he did not have a Lovable account, so engineers had to convert and deploy the app. WorkOS responded with company-wide Claude days, where non-engineers build while engineers coach, plus WOW, a CLI installed on every employee laptop. WOW creates a repository, checks tools such as GitHub and Doppler, applies a template, and deploys an app. Atlas provides the infrastructure underneath. It hides the deployment target, protects apps with company SSO, logs requests, manages secrets, and lists apps in a catalog. Galow shares usage data from 278 apps and explains that 37% of regularly used apps have had no engineer involved in their commits. WorkOS plans to add more granular permissions, data integrations, and Slack support.
AI made building cheap while shipping remained difficult
Galow separates creating an app from making it usable inside a company. Tools such as Lovable, Claude Code, and Codex make it easy to reach a running development app with a command such as npm run dev. The harder questions remain: where should the app run, how should employees authenticate, and how can the team prevent it from becoming public or exposing API keys? Non-engineers may lack access to Vercel or Cloudflare accounts, while engineers do not want to repeat the deployment work for every small internal tool.
WorkOS wanted anyone to build, ship, and share without infrastructure approval
WorkOS identified two requirements. Any employee should be able to build and ship an application without asking infrastructure teams for provisioning or security approval for standard apps. Once shipped, the app should be easy to share in Slack, so another employee can click a link and open it without extra red tape. Galow describes this as part of the applied AI team's work to make AI useful across the company, rather than limiting it to software development.
Claude days put non-engineers at the keyboard and engineers in a coaching role
WorkOS runs single-day hackathons called Claude days. Teams often pair a non-engineer with an engineer, but the non-engineer does the building. The engineer consults, unblocks problems, and acts as a sounding board. Sales and marketing employees bring ideas from their own work, then use AI to build tools that would previously have been difficult to bring to life. This gives the company a way to collect feedback about what people actually need from its internal app platform.
The WOW CLI prepares a complete app setup with one command
WOW is installed on every employee laptop through WorkOS's mobile device management system. The wow app create command checks whether Git, Node, GitHub, and Doppler are installed and configured. It creates a repository in the enterprise GitHub account, applies a Node.js template, pushes the files, and runs the deployment process. The demo ends with a working internal app available locally and deployed on Cloudflare. Employees do not need to understand each underlying setup step before they start building.
A shared skills repository lets employees reuse useful workflows
WorkOS also maintains a shared skills repository. An employee who creates a useful skill can push it for everyone else to find and fetch. Galow presents this as a way to reuse workflows while building with Claude Code or Codex. The repository extends the one-command setup with shared knowledge, so employees can draw on work that another person has already packaged instead of starting from the same process each time.
Atlas hides infrastructure while making internal apps secure and discoverable
Atlas is the platform underneath WOW. Galow gives it three design principles: infrastructure should be invisible, apps should be secure by default, and employees should be able to discover them. Atlas currently runs on Cloudflare Workers, but builders should not need to know that or care if the deployment target changes. Each app receives compute, storage, D1 databases, and KV values, then gets a host under workos.tools. The internal catalog records deployed apps so people can find them.
Company SSO, logs, and managed secrets are part of the default deployment
Apps are protected by WorkOS's Okta SSO account, so someone without access to the company account cannot open them. APIs and Slack bots can use token-based authentication where needed. Atlas logs requests for auditing and possible security investigations, while Doppler stores secrets so builders do not put credentials into a Git repository. Galow says the initial default is broad company access, with more granular group-based and role-based permissions planned for sensitive apps.
Internal app usage has grown beyond small dashboards
Galow reports 278 apps in the internal registry and 3.3 million requests over the previous week. About 60 apps are deployed, maintained, or used regularly, and some have custom domains. The apps include newsletter and changelog tools, a host for arbitrary HTML, APIs, Slack bots, and sales tools used by other systems. Among the 60 regularly used apps, 37% were built without engineers appearing in any commit. WorkOS plans to add Snowflake access and automatic Slack app installation.
