Let Anyone at Your Company Ship Internal Apps with AI — Garrett Galow, WorkOS

An account executive at WorkOS built a chatbot before going on leave. It drew on her sales calls and product knowledge so the rest of the sales team could keep using what she knew. Lovable helped her get the app working, and she shared it with her coworkers. Then CEO Michael tried to open it: “You don't have access.” He did not have a Lovable account.

The fix required two engineers from the applied AI team to convert the chatbot into an application WorkOS could deploy and give everyone access to. The account executive had already supplied the idea and built a useful tool. Making it useful to other people introduced another project: move the code, deploy it, manage it and arrange access. Garrett Galow, from the WorkOS product team, opens with this failure because it separates two jobs that are easy to conflate: building an app and shipping it.

AI had made the first job much cheaper. Lovable, Claude Code and Codex could help someone produce an application they could run with npm run dev. The second job still required decisions about hosting, accounts, employee authentication and secrets. A non-engineer might have neither a Cloudflare or Vercel account nor the knowledge to configure one. Engineers could do the work, but repeating it for every small internal tool consumed their time too. And a quick deployment could create a lasting problem if an API key ended up in the repository.

WorkOS needed two capabilities to arrive together:

• Self-service publishing. Anyone should be able to build and ship a standard internal application without asking infrastructure staff to provision it or seeking a separate security approval each time.
• Immediate distribution. Once published, the app should work for a coworker who clicks its link in Slack. Sharing the URL should not start another round of account setup or access requests.

Company-wide “Claude days” supplied a practical way to test that experience. These were single-day hackathons, typically pairing non-engineers with engineers. The non-engineer kept their hands on the keyboard; the engineer coached, helped resolve problems and acted as a sounding board. This arrangement let marketing and sales staff build around problems they understood while exposing the places where the development process still stopped them. The applied AI team's remit was to make AI useful across the company, so feedback from those builders mattered as much as improvements to engineers' workflows.

The first piece was WOW, a CLI that prepared the development environment and generated an app. WorkOS distributed it through mobile device management, pushing it to every employee's machine so it was available from day one. That distribution decision removed an earlier prerequisite: people did not first have to discover, install and configure the tool that would help them build.

The app-creation command asks for a name and checks the machine's prerequisites, including Git, GitHub login and Doppler, which WorkOS uses for secrets management. WOW handles development-machine preparation rather than leaving a new builder to discover missing tools one error at a time. A shared skills repository complements the CLI: employees can publish useful skills, browse what others have contributed and pull those skills into their own workflows.

The live example starts with an app named AIE demo. On Galow's already-configured machine, WOW checks Git, Node, GitHub and Doppler, confirms sign-in, and creates a repository in the company's enterprise GitHub account from a predefined template. The template is a mostly blank Node.js application. WOW pushes it, runs it and carries out a deployment step; Galow then opens the example at localhost. The visible change is concrete: a folder and an app name become a repository and a running application through one command. This demonstration shows the prepared-machine path rather than a first-time installation.

Only after that starting point is running does Claude receive the request to add something interesting for the demo. The order matters. Repository setup and the path to running the application are already established before the builder asks AI to change its behavior. Galow leaves that generation running in the background and moves on to existing apps, so the demo's demonstrated result is the working template, rather than a completed AI-generated feature.

Every app pushed through WOW enters an internal registry. At the time of the demonstration, it contained 278 apps, with 21 having had a deployment that day and 3.3 million requests passing through the applications over the previous week. Sixty had custom domains. The registry included APIs and Slack bots as well as browser-based tools, so its activity extended beyond people opening dashboards.

Two publishing tools show the kind of work this enables:

• Monthly newsletter preparation. Connor on the product marketing team needed to turn product updates into messages for both Slack and email. The internal tool pulls in changelogs, lets the author curate them and provides a place to design the Slack message. It brings the repeated collection and formatting work into one interface.
• Changelog drafting and publication. Galow's tool lets anyone at the company draft an update without working directly through Webflow's CMS interface. A draft triggers a Slack notification; Galow can review it and publish it when ready.

The changelog example is a useful distinction between app deployment and the workflow inside an app. Employees can deploy the tool and contribute drafts, while publishing a product update still passes through review. The tool changes how a draft reaches the reviewer: write it in the internal interface, notify through Slack, review, then post it live. Removing the engineering handoff does not require removing the editorial decision.

Access protection also becomes visible during these examples. Galow has to sign in with Okta and later refresh his authentication before continuing. These applications contain company work and are available to authenticated employees; knowing the URL alone does not grant an outsider access.

WOW is the interface employees use. Atlas is the infrastructure underneath it, supporting creation, building, deployment and sharing. Its design follows three principles:

• Invisible infrastructure. A builder should not have to choose or understand the deployment target. Atlas currently uses Cloudflare Workers; a future move to Vercel or AWS should be transparent to the builder.
• Security by default. Customer and sales tools can hold personally identifiable information, so protection cannot depend on every author remembering to add it.
• Discovery and access. A coworker should be able to find an app or follow its Slack link and use it through the company's existing identity system.

Atlas packages compute and storage together on Cloudflare's developer platform, including D1 databases and KV storage. A builder who needs persistent data does not have to begin a separate provisioning conversation. When an app is pushed, Atlas hosts it under WorkOS.tools, with a hostname derived from the app's name. Hosting, storage and a predictable address are parts of the normal publishing path.

The platform supplies several different security mechanisms:

• Employee authentication. Apps automatically sit behind WorkOS's Okta SSO, so browser users must have access to the company account.
• Programmatic authentication. APIs and Slack bots can enable token-based access, allowing software to call tools without relying on an interactive browser login.
• Request auditing. Requests are logged so suspected leaks or security incidents can be investigated through traffic records.
• Managed secrets. Doppler stores credentials for internal and third-party services, taking routine secrets management out of each app author's workflow.

Publishing and access answer different questions:

Catalog discovery does not replace authentication. The planned finer-grained authorization would further restrict which authenticated employees can use particular apps.

The hundreds of registry entries are not all maintained products. Galow narrows the useful population to about 60 apps being deployed, maintained or used regularly. One lets employees upload arbitrary HTML and receive a shared link—a small host for mocks, diagrams and similar artifacts. The platform supports these modest conveniences alongside more connected internal systems.

Weekly request volume also needs the right interpretation. The more than three million requests include people, machines and agents. Wallaby, a sales tool, exposes APIs that make its data available to other systems and Slack. Traffic therefore measures use of the infrastructure, rather than three million human visits.

The metric closest to the original goal is authorship: 37% of those roughly 60 apps had no engineers in any of their commits. Galow treats this as evidence that employees could build with Claude and ship without asking engineers to migrate or manage the resulting tool. Commit authorship measures independence at the application layer; it does not remove the engineering work that built WOW and Atlas or establish that no informal coaching occurred. The platform makes that shared engineering investment available to many builders.

Company-wide access solves the original distribution problem, but some sensitive apps should have a smaller audience. Granular authorization is a planned addition: Atlas already knows the user's identity at login, and WorkOS wants to make group-based and role-based permissions easy to apply. SSO determines who the employee is; the next layer would determine which authenticated employees may use a particular app.

Two integration directions extend the same approach:

• Data access as a capability. WOW and Atlas already have a capability mechanism for adding access such as Snowflake without requiring the author to handle API keys. WorkOS wants to expand the available integrations so requesting a data source can bring the maintained access setup with it.
• Slack installation with deployment. Existing tools already use Slack, but WorkOS is building an included integration that would automatically install a Slack app when an internal app is deployed. Employees could mention the tool to ask a question or drive a workflow where they already work.

The ending returns to the constraint exposed by the sales chatbot. Earlier internal-tool platforms still required engineers to build and maintain tools, limiting what the company could create. AI lowered the cost of building; Atlas supplied the additional capabilities needed to make those apps available across the team. The practical design choice is to put hosting, identity, secrets and discovery into a shared platform, so each new builder can spend their effort on the problem that brought them to the keyboard.