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

Good afternoon, everybody. My name is Garrett. I am on the product team at WorkOS, and you may see that the title of this slide, uh, this talk has slightly changed. Uh, that's the bad news. The good news is that the talk is better for it because, the original idea I had for this talk two months ago, uh, is already sort of out of date with how quickly things move. So today, we're gonna talk about how do we enable anyone at your company to ship? There are lots of people at your company that have great ideas of things that will

solve problems inside your company. But even with AI, the technology still holds them back. So I wanna tell you the story of how we dealt with this problem, what we did about it, and give you some advice if you're gonna do it yourself, or talk about what we're gonna offer to help folks with this problem.

So this was about six, eight months ago. Uh, one of our account executives, [REDACTED], she was about to go on [REDACTED]. She's a incredible AE, and she wanted to build something to help the rest of the sales team while she was on leave. So she went and built something called [REDACTED] GPT. Uh, it's basically a chatbot trained on her sales calls and all the stuff she knew about the product to help other people, uh, while she was out. So she went, she built this. At the time, she used

Lovable, all this stuff. She got it working great. She shared it, said, "Hey, I have this tool that you can use while I'm out. I hope it's helpful."

First thing, our CEO, Michael, tries to use the tool, and he gets this, "You don't have access." He doesn't have a Lovable account 'cause he's not, not used Lovable. Uh, and so he can't use it. And so he's like, "Hey, how... What can we do here? How do we make sure everyone can use it?" And so the solution was, "Hey, two engineers on our applied AI team, can you go convert this into, like, a app that we can deploy and that we can give everyone access to?" So now we have a, a account

exec who comes up with a great idea, but in order to make that idea actually useful, we have to go get engineers to spend a bunch of time, uh, recode it, you know, move it from Lovable, deploy it, manage it, all this kinda stuff. And this is really painful because really, what should happen is she creates the app, deploys it, shares it, everyone gets access, and now people are, are using it.

And so building things got cheap, right? She was using Lovable. That was kind of, you know, right around when, like, Opus four eight was coming out. Now people are using Claude Code, Codex, and stuff in many cases. And so it's not hard to build a thing, something that you can, you know, npm run dev. It's pretty easy now. But shipping it, making it available, even internally to your company, hasn't really gotten that much easier, right? Where do you deploy this? Where are you gonna run this app? How do you ensure it's secure, right? How are people gonna-- You wanna all have your internal

employees authenticate to it, but you don't want it to be publicly available. And so, you know, for a less technical person, for a non-engineer, they're gonna struggle with, you know, "Do I put it on Vercel? Well, I don't have access to a Vercel account or a Cloudflare account 'cause I'm not an engineer." Uh, and they might not know the details of how to do that. Even for engineers who know how these tools work, they don't really wanna have to go through this and do it from scratch every single time. And then if you're deploying these things internally, you want them to have auth and security baked in. You don't want

people just, you know, shipping API keys to stuff. That might get, like, checked into code bases or stuff like that. Um, and so what do you do? You end up burning a bunch of engineering time to say, "Hey, this is important. We need to go convert this to be some proper app deployment."

So the thing we needed at WorkOS was kind of two things. One, the capability for everyone at the company to be able to build and ship an application. They shouldn't need to go ask infra for provisioning. They shouldn't need to get, like, security approval for standard apps. They should just be able to build the thing and make it available. And two, we wanted distribution, right? We want, as soon as they ship it, they can link someone else to it. That person can click the link in Slack, open it up, and access the application without any red flags or any kind of red

tape. And so we wanted to move fast. We wanted to build quickly. We have this applied AI team at WorkOS whose, their kind of singular job is, how do we make AI more and more useful across the company? Not just, you know, how do we move the software development process along and make engineers useful with AI, but how do we make everyone useful with AI? Building, you know, building is cheap, right? We could build a thing, no problem. But how do we know it works? We need to get the feedback around it. Turns out, we basically had,

uh, sort of a forcing function to gather feedback, which is we'd started doing these company-wide Claude days. Basically, it's a single day hackathon where everyone pairs up into teams and builds an app. And typically when we do this, we actually pair non-engineers with engineers, and we actually have the non-engineers do the building. They're the ones that have our hands on keyboard. They're the ones building the application. Uh, while the engineer that's paired with them is there to consult, help them, you know, unblock them with any issues they find so they don't get stuck, kinda be a sounding board for, you know, how they can approach

this. But we have a ton of our, you know, marketing folks and sales folks that have all these really great ideas of apps that, you know, they've maybe struggled to bring to life.

So we built two things. The first thing is we built a CLI. We call it Wow. Wow is the thing that helps you build and generate an app without needing to know any of the underlying details. It basically is a toolkit that helps you, uh, set up Git, set up a repo, clone in an example application that you can use to start with for Claude Code or Co- Codex, uh, to build the app you wanna build. And we distribute it to every single employee at the company through our MDM. We just push it onto your machine so every employee, day one,

has access to this tool.

The Wow CLI lets you run things like Wow app create. And what it does is it, you name the app, it scans your machine and says, "Okay, do you have Git installed? Do you have, are you logged into GitHub? Do you have Doppler?" Which is where we do secrets management. It kind of does all this, uh, pre-configuration of your developer machine, uh, whether you're an engineer or not, uh, so that everything is kind of ready to go, and you're not gonna hit any snags along the way.

We also built a shared skills repository, so anyone at the company can, if they've built a skill that's useful, they can push that skill up, and it's shared to everyone, and then it's easy to fetch those skills, see what's available, and pull skills down to help you build things or, or do certain workflows.

So I'm gonna do a quick demo to kinda show you a little bit of what this looks like. Um, so here I'm in this folder, and I wanna create an app. Let's do AIE demo.

And so it basically runs through this whole floo- flow. I've already obviously configured my machine. It's not the first time I'm doing this. So it checks I have Git, I have Node, GitHub, Doppler. I'm signed in. I have everything. And what it does, it actually creates a repo in our enterprised GitHub account. Uh, it uses a kind of a template that we already have defined. So it starts out with basically a kinda blank Node.js app. Um, so it does that, pushes everything, runs it, and then, you know, now we get some-

something that I can run internally or locally.

It does a little, uh, deploy step, and then we get something available at localhost that I can pull up here.

And we have this internal app example. If it's not obvious, we're running this on Cloudflare, um, 'cause it makes it real easy to quickly deploy, um, a Node app. So this is great. Single command, I now have this app running. And then from that point on, you know, I can just, you know, pop into Claude and say, "Hey, I'm doing a demo for AIE. What can we put in this app that would be cool?"

So I'm gonna let this go off. I don't know. We're gonna see what it does. Um, this is sorta just Claude being Claude. But, um, I wanna walk through, like, a few parts of, uh, what we built and some examples of the things we've built. So we have this, uh, internal registry. So any time you push an app with Wow, uh, we actually log it into this internal registry. So you can see we have two hundred and seventy-eight apps that have been pushed, uh, twenty-one that we're... had a deployment done today. Uh, over the last week, we've had three point three million requests go through these

applications. So these aren't just little dashboard tools. They're also APIs, Slack bots, and things that we've created and use internally ourselves. Um, and then sixty of these are on sorta custom domains, so they have their own, uh, like, branded, um, domain name. A couple examples of things we've built is, um, Connor on our product marketing team, we send these monthly newsletters that are like, "Hey, what's the latest in WorkOS?" Uh, it's kind of a pain. We have to take updates that we have, put them into a format, and then we need to format them to send in both

Slack and over email, um, which is pretty annoying. And so we built this, uh... I think my auth... So here's how these apps are protected, right? I have to l- log in with my Okta account in order to access them. So if you go to, uh, any of these URLs, you'll see, uh, you won't be able to get to them. So here it basically pulls in, uh, all of our change logs. You can curate that. You can design what the Slack message is gonna look like. And so it's a kind of singular place to design this

experience. A thing that I built is, uh, we have a change log, change log, workos.com/changelog is where we post all our updates. And we do this through Webflow, which is, like, a CMS platform. But it's, it's pretty painful to actually, like, go in, design the change log post, and do all of this stuff. And so I built a tool that basically allows anyone at our company to draft these change logs. And so someone can come in... Ooh. I gotta refresh my auth.

There we go. Uh, anyone can come in, kinda draft these change logs, and then it posts into Slack, so I can know, "Hey, there's a new change log. Someone's drafted up." I can review it, and then when it's ready, I can post it, and it posts it live. So this is what it, the kind of tools that we're able to build. Basically, anyone at our company can now self, you know, spin up Claude code, build the app that they want, and deploy it live, make it available to the entire company. I'm gonna, I'm gonna let that just sit in the background. We don't need to see what that does.

Um, but yeah. So that's, that's the kind of idea. Now we have, uh, tons of people at the company building these tools. Uh, nothing gets in the way. They don't have to ask for, "Hey, can someone deploy this? Hey, can someone provision some account for me?" Uh, everyone by default in the company can use this tool. So I wanna talk a little bit about Atlas, which is the actual platform underneath this that empowers this, this, this tool. Wow is just sort of the CLI that people use to interface with it, but Atlas is actually the underlying infrastructure. Basically, Atlas

allows you to create, build, deploy, and share these applications. There are sort of three principles when we were building Atlas that we wanted to maintain a- and ensure that provided a great experience. One was we wanted the infra to be invisible. No one should need to know where the deployment target is. It happens to be that we're running on Cloudflare workers. If at some point we wanna change that to Vercel or AWS, it shouldn't matter. It should be transparent to anyone trying to build and deploy these applications. We want it to be secure by default, right? We don't wanna risk those... I can't show you all of the apps that we

built. Some of them have a lot of PII. They're customer tools, sales tools that we use. So we don't want anyone just to be able to access these tools outside the company because they're very sensitive. And then last is the discovery, discoverability. Someone shares a link in Slack, anyone should be able to click that and be able to view that tool.

So today Atlas runs on Cloudflare's developer platform. Every app, when you run that WOW create step, provides compute, storage, uh, with D1 databases, KV values, all the bits and pieces you need. So you don't have to ask like, "Oh, well if I need to like store persistent data, am I gonna be able to do that?" It's, it's already part of the package. Um, and we automatically host all of these tools when you push them under WorkOS.tools. So we have this shared domain that whatever your app is called, you get that host name underneath WorkOS.tools. So you don't have to worry about where is the app gonna be

available, how does it get... you know, do people get access?

Secure by default. So all of these apps are automatically protected by our Okta SSO account, so you can't log in if you don't have access to our Okta account. We've actually built for APIs and Slack bots. We've built a way to actually plug holes for a token-based authentication. And so if that's something you need, you can build out, uh, you can kind of enable that and then get API access for some of these tools that we're using. All the requests are logged and auditable, so we have logs of all the traffic that's happening. So if we think there was some sort

of leak or, um, security issue, like we can go and detect what happened. And then all the secrets, so if you need API access to any of our tools, internal tools or third party tools, that's all stored securely. Uh, we use Doppler in this case, and so you don't really have to do secrets management. You don't have to worry about did I, you know, push a secret into the Git repo that's now, you know, uh, a problem. It's all done securely. And then last we have the catalog for discovery. Every app's discoverable. Um, no need to

share. You don't, we don't need to have sharing support because you by default have access.

So I think so far, you know, I showed you that catalog page which had a few hundred apps. Obviously not every single app is super important and sees the light of day, but we have about sixty apps that are been deployed, maintained, or getting used on a regular basis. So this isn't just like two tools people built that are useful. This is actually becoming, uh, a way in which things are being maintained. We actually had someone build a tool where you take any arbitrary HTML, upload it, and it gives you a shared link. So it's basically like a mini hoster of like mocks or diagrams or

things that you can easily share. We're seeing over three million requests a week on- run through all of these apps. Um, this is partially users using traffic, but it's also, um, one of our tools, Wallaby, is like a sales tool and we actually built APIs for that that allows us to access that data in other systems in Slack. And so it's not just humans acce- accessing this data, it's machines and agents as well. We've completely eliminated the need for, uh, asking for help in deploying applications because nothing stops anyone anymore. And I think like

the most important metric is, you know, our, our goal was enable non-engineers to build and deploy apps. And out of our apps, out of these sixty apps, thirty-seven percent of them have been built without any engineers in any of the commits. So they're totally built between that person and Claude without engineering involvement. And that's sort of the marker of like a true success here that we've actually eliminated the need for, "Hey, engi... you know, some engineer, can you migrate this tool? Can you manage this tool on behalf of, you know, marketing or sales?"

So there's more that we wanna do here. This is sort of a initial version. We wanna add granular auth. Not every app should necessarily be open by default to everyone in the company obviously. There's some sensitive data in some cases. So we want to add-- We already know who the user is when they're logging into the app, so we wanna support doing kinda like group-based, role-based permissions for these apps easily. We wanna add more data integration, so we kind of already have this capability aspect to, to WOW and to Atlas where if I need access to our Snowflake data, for example, I don't need to go kind

of think about API keys. I can just say, "I want to add Snowflake," and now the app has correctly maintained Snowflake access. And then the other thing that we've, we're building out is Slack integration. So a lot of these tools are great, but you really want them, uh, to be available inside Slack so that someone can just at the tool and get, you know, answer a question, get use out of it, or actually drive a workflow. And so we're building, uh, included Slack integration. So someone deploys an app, they can also get the Slack app, um, automatically installed.

So for us, we're kind of experiencing ourselves a revolution in internal app development. We've used other platforms to build certain tools. We've always found them very cumbersome. Uh, they basically still took engineers to build and maintain, and it sort of limited the tools that we could build. For us, AI solved the build problem, but we needed more in order to make this a ubiquitous platform for our, our, our team. Atlas provides us capabilities to enable anyone at our company to ship internal apps. And if you're interested in having this kind of

capability at your company, I'd love to talk to you about it. Thank you.