Permita que qualquer pessoa da sua empresa publique apps internos com IA — Garrett Galow, WorkOS

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Let Anyone at Your Company Ship Internal Apps with AI — Garrett Galow, WorkOS · Canal: AI Engineer · 16:51 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Garrett Galow conta como a WorkOS tornou possível que funcionários sem experiência em engenharia criem e publiquem apps internos com ajuda de IA, sem depender de engenheiros para cada etapa de implantação. A empresa desenvolveu o CLI Wow e a plataforma Atlas para automatizar a configuração, a hospedagem, a autenticação e a descoberta dos apps. O sistema já sustenta centenas de apps, incluindo ferramentas usadas por equipes de vendas e marketing, e 37% dos apps mantidos regularmente foram criados sem participação de engenheiros nos commits. A equipe pretende ampliar permissões granulares, integrações de dados e suporte ao Slack.

Pontos-chave

• A IA tornou mais fácil criar apps, mas publicar, proteger e distribuir esses apps internamente ainda exigia trabalho de engenharia.
• A WorkOS buscou permitir que qualquer funcionário criasse e compartilhasse apps sem pedir provisionamento de infraestrutura ou ajuda para implantação.
• O CLI Wow automatiza a configuração da máquina, a criação de um repo e o início de um app a partir de um modelo.
• A plataforma Atlas fornece hospedagem, armazenamento, autenticação corporativa, gerenciamento de secrets e registros de tráfego.
• Os Cloud Days ajudam a coletar feedback: funcionários que não são engenheiros desenvolvem apps com apoio consultivo de engenheiros.
• O catálogo interno facilita a descoberta dos apps, que podem ser acessados por funcionários autenticados.
• A WorkOS relata que 37% dos 60 apps implantados, mantidos ou usados regularmente foram criados sem engenheiros nos commits.
• Entre as próximas melhorias estão permissões por grupo e função, integrações com fontes de dados e instalação automática de apps no Slack.

Capítulos

Início	Capítulo	Resumo
00:12	O desafio de disponibilizar apps internos	Garrett apresenta o caso de Perona GPT e explica por que criar um app não bastava se os funcionários não conseguiam acessá-lo.
03:25	Construção de apps por toda a empresa	A WorkOS define o objetivo de permitir que funcionários criem e compartilhem apps, e usa Cloud Days para experimentar essa abordagem.
05:01	O CLI Wow em ação	Garrett demonstra como o Wow configura o ambiente, cria um repo e inicia um app que pode ser executado e implantado.
11:02	Atlas: infraestrutura, segurança e descoberta	A apresentação descreve como Atlas oferece hospedagem, autenticação, gerenciamento de secrets e um catálogo para encontrar os apps.
14:46	Resultados e próximos passos	Garrett relata a participação de não engenheiros na criação dos apps e apresenta planos para permissões, integrações de dados e Slack.

Citações

Criar ficou barato; disponibilizar o app, mesmo internamente, não ficou muito mais fácil. — 02:20

Assim que publicam, podem enviar o link para outra pessoa, que consegue abrir e acessar o app. — 03:56

A infraestrutura deve ser invisível. — 11:33

37% dos nossos apps foram criados sem engenheiros em nenhum dos commits. — 14:46

Conceitos e entidades

• WorkOS (empresa): Empresa onde Garrett Galow trabalha e cuja equipe desenvolveu ferramentas para criar e distribuir apps internos.
• Garrett Galow (pessoa): Integrante da equipe de produto da WorkOS que apresenta a experiência da empresa com apps internos criados com IA.
• Wow (ferramenta): CLI da WorkOS que automatiza a configuração e a criação de apps internos.
• Atlas (ferramenta): Plataforma de infraestrutura da WorkOS que permite criar, implantar e compartilhar apps internos.
• Cloudflare (empresa): Empresa cuja plataforma de desenvolvimento hospeda os apps internos descritos na apresentação.
• Doppler (ferramenta): Ferramenta usada pela WorkOS para armazenar secrets com segurança.
• Cloud Days (conceito): Hackathons de um dia na WorkOS em que equipes desenvolvem apps, frequentemente com funcionários não técnicos na construção.
• Perona GPT (ferramenta): Chatbot criado por uma executiva de contas com base em suas chamadas de vendas e conhecimento do produto.

Tradução completa (pt-BR)

00:12 Boa tarde a todos. Meu nome é Garrett. Faço parte da equipe de produto da WorkOS, e talvez vocês tenham notado que o título deste slide e desta palestra mudou um pouco. Essa é a má notícia. A boa notícia é que a palestra ficou melhor por causa disso, porque a ideia original que eu tinha para esta palestra, há dois meses, já está meio desatualizada, considerando a rapidez com que as coisas mudam. Então, hoje vamos falar sobre como permitir que qualquer pessoa na sua empresa publique aplicativos. Há muitas pessoas na sua empresa com ótimas ideias de coisas que resolveriam problemas dentro dela

00:44 mas, mesmo com IA, a tecnologia ainda as impede. Então, vou contar a história de como lidamos com esse problema, o que fizemos a respeito e dar alguns conselhos caso vocês queiram fazer isso por conta própria, ou falar sobre o que vamos oferecer para ajudar as pessoas com esse problema. Isso foi há uns seis ou oito meses. Uma das nossas executivas de contas, Perona, estava prestes a sair de licença-maternidade. Ela é uma executiva de contas incrível e queria criar algo para ajudar o restante da equipe de vendas enquanto estivesse de licença. Então, ela criou algo chamado

01:16 Perona GPT. Basicamente, é um chatbot treinado com as ligações de vendas dela e tudo o que sabia sobre o produto, para ajudar outras pessoas enquanto ela estivesse fora. Na época, ela criou isso usando lovable. Fez tudo funcionar muito bem. Compartilhou e disse: “Ei, tenho esta ferramenta que vocês podem usar enquanto eu estiver fora. Espero que seja útil.” A primeira pessoa a tentar usar a ferramenta foi nosso CEO, Michael, e ele recebeu a mensagem “você não tem acesso”. Ele não tem uma conta no lovable, porque não costuma usar o lovable

01:47 e, por isso, não consegue usar a ferramenta. Então, ele perguntou: “Ei, o que podemos fazer aqui? Como garantimos que todos possam usar isso?” E a solução foi: “Ei, dois engenheiros da nossa equipe de IA aplicada, vocês podem transformar isso em um aplicativo que possamos fazer deploy e disponibilizar para todos?” Então, temos uma executiva de contas que tem uma ótima ideia, mas, para que essa ideia seja realmente útil, precisamos pedir aos engenheiros que gastem bastante tempo reescrevendo o código, transferindo-o do lovable, fazendo o deploy, gerenciando tudo isso e assim por diante.

02:20 E isso é muito frustrante, porque o que deveria acontecer é: ela cria o aplicativo, faz o deploy, compartilha, todos conseguem acessar e, então, as pessoas passam a usá-lo. Criar coisas ficou barato, certo? Ela estava usando lovable, mais ou menos na época em que Opus 48 estava saindo. Hoje, em muitos casos, as pessoas estão usando Claude Code, Codex e coisas do tipo. Então, não é difícil criar algo que, por exemplo, você consiga executar com npm run dev. Agora isso é bem fácil. Mas fazer o deploy e disponibilizar o aplicativo, até mesmo internamente na empresa, não ficou

02:52 muito mais fácil, certo? Onde você faz o deploy? Onde vai executar esse aplicativo? Como garante que ele seja seguro? Como as pessoas vão… Você quer que seus funcionários façam autenticação para acessá-lo, mas não quer que ele fique disponível publicamente. E, para alguém menos técnico, que não seja engenheiro, vai ser difícil decidir: “Coloco no Vercel?” Bem, não tenho acesso a uma conta do Vercel nem do Cloudflare porque não sou engenheiro. Talvez essa pessoa não conheça os detalhes de como fazer isso. Mesmo os engenheiros que sabem como essas ferramentas funcionam não querem ter que passar por tudo isso e fazer do zero toda vez.

03:25 E, se você está fazendo deploy dessas coisas internamente, quer que elas já venham com autenticação e segurança integradas. Você não quer que as pessoas simplesmente enviem chaves de API para coisas que podem acabar, por exemplo, em repositórios de código. Então, o que fazer? Você acaba gastando bastante tempo dos engenheiros para dizer: “Ei, isso é importante. Precisamos transformar isso em um aplicativo adequado para deploy.” O que precisávamos na WorkOS eram, basicamente, duas coisas. Primeiro, a capacidade de qualquer pessoa na empresa criar e publicar um aplicativo.

03:56 As pessoas não deveriam precisar pedir à equipe de infraestrutura que provisionasse algo. Não deveriam precisar de aprovação da equipe de segurança para aplicativos comuns. Deveriam simplesmente criar o aplicativo e disponibilizá-lo. Segundo, queremos distribuição, certo? Queremos que, assim que alguém publique o aplicativo, possa enviar o link para outra pessoa. Essa pessoa pode clicar no link no Slack, abri-lo e acessar o aplicativo sem alertas nem burocracia. Então, queremos avançar rápido. Queremos criar coisas rapidamente. Temos esta equipe de IA aplicada na WorkOS, cuja única função é descobrir como tornar a IA cada vez mais

04:28 útil em toda a empresa. Não apenas descobrir como avançar no processo de desenvolvimento de software e tornar os engenheiros mais produtivos com IA, mas como tornar todos mais produtivos com IA. Criar coisas ficou barato, certo? Podemos criar algo sem problema. Mas como sabemos se funciona? Precisamos obter feedback sobre isso. Acontece que tínhamos uma espécie de mecanismo que nos obrigava a coletar feedback: começamos a fazer estes Cloud Days para toda a empresa. Basicamente, é uma maratona de programação de um dia em que todos formam equipes e criam um aplicativo. E, geralmente, quando fazemos isso, juntamos pessoas que não são engenheiras com

05:01 engenheiros. E fazemos com que as pessoas que não são engenheiras construam o aplicativo. São elas que ficam com as mãos no teclado. São elas que criam o aplicativo. Enquanto isso, o engenheiro que está trabalhando com elas fica por perto para dar consultoria, ajudar a resolver qualquer problema que apareça, para que elas não fiquem travadas, e servir como interlocutor para pensar em como abordar as coisas. Temos muitas pessoas da equipe de marketing e da equipe de vendas com ótimas ideias de aplicativos que talvez tenham tido dificuldade para transformar em realidade. Então, criamos duas coisas. A primeira foi um CLI. Nós o chamamos de wow. O wow é o que

05:34 ajuda você a criar e gerar um aplicativo sem precisar conhecer nenhum dos detalhes técnicos por trás dele. Basicamente, é um conjunto de ferramentas que ajuda a configurar o Git, criar um repo e clonar um aplicativo de exemplo que você pode usar como ponto de partida para usar com Cloud Code ou Codex e criar o aplicativo que quiser. E distribuímos isso a todos os funcionários da empresa por meio do nosso MDM. Simplesmente instalamos nas máquinas de vocês. Assim, desde o primeiro dia, todos os funcionários têm acesso a essa ferramenta. O CLI wow permite executar comandos como wow app create. O que ele faz é

06:06 pedir que você dê um nome ao aplicativo, examinar sua máquina e dizer: “Certo, você tem o Git instalado? Fez login no GitHub? Tem o Doppler, que é a ferramenta de gerenciamento de secrets?” Ele faz toda essa pré-configuração da máquina de desenvolvimento, quer você seja engenheiro ou não, para deixar tudo pronto e evitar que você encontre obstáculos pelo caminho. Também criamos um repositório compartilhado de skills. Assim, qualquer pessoa na empresa que tenha criado uma skill útil pode enviá-la para lá, e ela fica compartilhada com todos. Depois, é fácil buscar essas skills, ver o que está

06:36 disponível e baixar skills para ajudar a criar coisas ou executar determinados workflows. Vou fazer uma demonstração rápida para mostrar um pouco como isso funciona. Então, estou nesta pasta e quero criar um aplicativo. Vamos chamá-lo de AIE demo. Ele passa por todo este fluxo. É claro que já configurei minha máquina. Não é a primeira vez que faço isso. Então, ele verifica se tenho o Git, o Node, o GitHub e o Doppler, se estou conectado, enfim, tudo. E

07:10 o que ele faz é criar um repo na nossa conta corporativa do GitHub. Usa um modelo que já definimos. Então, começa basicamente com um aplicativo Node.js em branco. Ele faz isso, envia tudo, executa e, agora, temos algo que posso executar internamente ou localmente. Ele faz uma pequena etapa de deploy e, então, temos algo disponível em localhost que posso abrir aqui.

07:45 E temos este exemplo de app interno. Se não ficou óbvio, estamos executando isso na Cloudflare, porque ela facilita muito fazer o deploy rápido de um app Node. Então, isso é ótimo. Um único comando e agora tenho este app em execução. E, a partir daí, posso simplesmente abrir o Claude e dizer: “Ei, estou fazendo uma demonstração para a AIE. O que poderíamos colocar neste app que seria legal?”

08:21 Então, vou deixar isso rodando. Não sei, vamos ver o que ele faz. Isso é meio que o Claude sendo o Claude, mas quero mostrar algumas partes do que criamos e alguns exemplos das coisas que construímos. Temos este registro interno. Sempre que alguém publica um app com o Wow, nós o registramos no registro interno. Como podem ver, temos 278 apps publicados, 21 dos quais receberam um deploy hoje. Na última semana, houve 3,3 milhões de solicitações feitas a esses aplicativos. Então, eles não são apenas

08:53 pequenas ferramentas de dashboard; também são APIs, bots do Slack e coisas que criamos e usamos internamente. E 60 deles estão em domínios personalizados, então têm seu próprio nome de domínio com marca. Alguns exemplos do que criamos: o Connor, da nossa equipe de marketing de produto, envia estes boletins mensais do tipo: “Ei, quais são as novidades mais recentes no WorkOS?” Dá um certo trabalho: precisamos pegar as atualizações que temos, colocá-las em um formato e, depois, formatá-las para enviar tanto pelo Slack quanto por e-mail, o que é bem irritante. Então, criamos este… acho que minha

09:28 autenticação. É assim que esses apps são protegidos, certo? Preciso fazer login com minha conta da Okta para acessá-los. Então, se você acessar qualquer um desses URLs, verá que não conseguirá entrar. Aqui, ele reúne todos os nossos registros de alterações. Você pode selecionar o que entra. Pode definir a aparência da mensagem do Slack. Assim, é um lugar único para criar essa experiência. Acho que o que eu criei foi… temos um registro de alterações. Changelog.workable.com/changelog é onde publicamos todas as nossas atualizações. E nós

09:59 fazemos isso pelo Webflow, que é uma plataforma de CMS. É bem, bem trabalhoso entrar, criar a publicação do registro de alterações e fazer tudo isso. Então, criei uma ferramenta que permite que qualquer pessoa na empresa redija esses registros de alterações. Alguém pode entrar e… Opa. Preciso atualizar minha autenticação. Pronto. Qualquer pessoa pode entrar, redigir esses registros de alterações e publicá-los no Slack, para que eu saiba: “Ei, alguém redigiu um novo registro de alterações. Posso revisá-lo.” E, quando estiver

10:31 pronto, posso publicá-lo e colocá-lo no ar. Então, esse é o tipo de ferramenta que conseguimos criar. Basicamente, agora qualquer pessoa na empresa pode iniciar o Cloud Code por conta própria, criar o app que quiser e fazer o deploy para deixá-lo disponível para toda a empresa. Vou deixar isso rodando em segundo plano. Não precisamos ver o que ele faz. Mas é essa a ideia. Agora temos muitas pessoas na empresa criando essas ferramentas. Nada fica no caminho. Elas não precisam pedir: “Ei, alguém pode fazer o deploy disto?” ou “Ei, alguém pode provisionar uma conta para mim?”

11:02 Por padrão, todos na empresa podem usar esta ferramenta. Quero falar um pouco sobre o Atlas, a plataforma que está por trás disso e que dá suporte a esta ferramenta. O Wow é basicamente a CLI que as pessoas usam para interagir com ela, mas o Atlas é a infraestrutura subjacente. Basicamente, o Atlas permite criar, desenvolver, fazer o deploy e compartilhar esses aplicativos. Ao criar o Atlas, queríamos manter três princípios para proporcionar uma ótima experiência. O primeiro era que a infraestrutura

11:33 fosse invisível. Ninguém deveria precisar saber qual é o destino do deploy. Por acaso, estamos usando o Cloudflare Workers. Se em algum momento quisermos mudar para Vercel ou AWS, isso não deveria fazer diferença. Deveria ser transparente para qualquer pessoa que queira criar e fazer o deploy desses aplicativos. Também queríamos que fosse seguro por padrão, certo? Não queremos correr o risco de… Não posso mostrar todos os apps que criamos. Alguns contêm muitas informações de identificação pessoal; são ferramentas para clientes e para a equipe de vendas que usamos. Portanto, não queremos que qualquer pessoa consiga acessar essas ferramentas de fora da empresa, porque elas são muito sensíveis. E, por último, vem a possibilidade de descoberta. Se alguém compartilhar um link no Slack, qualquer pessoa deve poder clicar nele e visualizar essa ferramenta.

12:08 Hoje, o Atlas roda na plataforma para desenvolvedores da Cloudflare. Cada app, quando você executa a etapa de criação com o Wow, recebe recursos de computação e armazenamento, com bancos de dados D1, valores KV e tudo de que precisa. Assim, você não precisa perguntar: “Ah, se eu precisar armazenar dados persistentes, vou conseguir fazer isso?” Isso já vem incluído no pacote. E hospedamos automaticamente todas essas ferramentas em workos.tools quando você as publica. Temos um domínio compartilhado: qualquer que seja o nome do seu app, você recebe esse nome de host sob workos.tools. Assim, você não precisa se preocupar com onde o app ficará disponível, como as pessoas vão acessá-lo…

12:39 A segurança é padrão. Todos esses apps são protegidos automaticamente pela nossa conta de SSO da Okta. Portanto, você não consegue fazer login se não tiver acesso à nossa conta da Okta. Para APIs e bots do Slack, também criamos uma forma de preencher as lacunas com autenticação baseada em token. Se precisar disso, você pode configurar e habilitar essa opção para obter acesso à API de algumas dessas ferramentas que usamos. Todas as solicitações são registradas e

13:10 podem ser auditadas. Temos registros de todo o tráfego. Se acharmos que houve algum vazamento ou problema de segurança, podemos investigar e detectar o que aconteceu. E todos os segredos — por exemplo, se você precisar de acesso à API de alguma das nossas ferramentas, internas ou de terceiros — ficam armazenados com segurança. Neste caso, usamos o Doppler. Assim, você não precisa gerenciar segredos nem se preocupar se enviou algum segredo para o repo do Git e isso virou um problema. Tudo é feito com segurança. E, por último, temos o catálogo para facilitar a descoberta. Todos os apps podem ser encontrados.

13:43 Não é preciso compartilhar. Não precisamos oferecer suporte para compartilhamento, porque, por padrão, você já tem acesso. Até agora, mostrei a página do catálogo, que tinha algumas centenas de apps. É claro que nem todos são superimportantes ou chegam a ser usados, mas temos cerca de 60 apps que foram publicados, são mantidos ou usados regularmente. Então, não se trata apenas de duas ferramentas úteis que alguém criou. Isso está se tornando uma maneira de manter ferramentas. Alguém criou uma ferramenta em que você pega qualquer

14:13 HTML arbitrário, faz o upload e recebe um link compartilhável. É basicamente um pequeno serviço de hospedagem para protótipos, diagramas ou outras coisas que você pode compartilhar facilmente. Estamos vendo mais de 3 milhões de solicitações por semana passando por todos esses apps. Parte disso é tráfego de usuários, mas uma das nossas ferramentas, Wallaby, é uma ferramenta de vendas, e criamos APIs para ela que nos permitem acessar esses dados em outros sistemas, como o Slack. Portanto, não são apenas pessoas acessando esses dados; máquinas e agents também acessam. Eliminamos completamente a necessidade de pedir ajuda para fazer o deploy

14:46 aplicativos, porque nada mais impede ninguém. E acho que, sabe, a métrica mais importante é… Nosso objetivo era permitir que pessoas que não são engenheiras criassem e publicassem aplicativos. E, dos nossos aplicativos — desses 60 aplicativos —, 37% foram criados sem que nenhum engenheiro participasse de qualquer um dos commits. Então, eles foram totalmente criados entre essa pessoa e o Claude, sem envolvimento da engenharia. E esse é mais ou menos o indicador de um verdadeiro sucesso aqui: eliminamos de fato a necessidade de dizer: “Ei, sabe, algum engenheiro, você pode migrar esta ferramenta? Pode gerenciar esta ferramenta em nome do pessoal de marketing

15:18 ou de vendas?” Então, ainda queremos fazer mais coisas aqui. Esta é mais ou menos a versão inicial. Queremos adicionar permissões granulares. Obviamente, nem todo aplicativo deve necessariamente ser aberto por padrão para todas as pessoas da empresa. Em alguns casos, há dados confidenciais. Então, queremos adicionar… Já sabemos quem é o usuário quando ele faz login no aplicativo. Por isso, queremos facilitar o uso de permissões para esses aplicativos baseadas em grupos e funções. Queremos adicionar mais integrações de dados. Então, já temos mais ou menos essa capacidade no Wow e no Atlas: se eu precisar acessar nossos dados no Snowflake

15:48 por exemplo, não preciso me preocupar com chaves de API. Posso simplesmente dizer: “Quero adicionar o Snowflake”. E então o aplicativo passa a ter acesso ao Snowflake corretamente configurado. A outra coisa que estamos desenvolvendo é a integração com o Slack. Muitas dessas ferramentas são ótimas, mas você realmente quer que elas estejam disponíveis dentro do Slack, para que alguém possa mencionar a ferramenta e obter uma resposta para uma pergunta, usá-la ou até mesmo conduzir um workflow. Então, estamos incluindo a integração com o Slack. Se alguém publicar um aplicativo, também poderá ter o app do Slack instalado automaticamente.

16:20 Então, para nós, estamos vivenciando uma revolução no desenvolvimento de aplicativos internos. Usamos outras plataformas para criar certas ferramentas. Sempre as achamos muito complicadas. Basicamente, elas ainda exigiam que engenheiros as criassem e mantivessem, o que limitava as ferramentas que podíamos criar. Para nós, a IA resolveu o problema da criação, mas precisávamos de mais para transformar isso em uma plataforma onipresente para toda a nossa equipe. O Atlas oferece esses recursos para permitir que qualquer pessoa da nossa empresa publique aplicativos internos. E, se você tiver interesse em ter esse tipo de recurso na sua empresa, eu

16:51 adoraria conversar com você sobre isso. Obrigado. >> [música] [música]

Transcrição original

[00:12] Good afternoon everybody. My name is Garrett. I’m on the product team at WorkOS and you may see that the title of this slide 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 going to 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

[00:44] but even with AI the technology still holds them back. So I’m going to tell you the story of how we dealt with this problem, what we did about it and give you some advice if you’re going to do it yourself or talk about what we’re going to offer to help folks with this problem. So this was about six eight months ago. Uh, one of our account executives Perona she was about to go on maternity leave. 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

[01:16] Perona 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 the stuff she got it working great. She shared it and 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 cuz he’s not not used lovable

[01:47] 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 an app that we can deploy and that we can give everyone access to? So now we have 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 recode it, you know, move it from lovable, deploy it, manage it, all this kind of stuff.

[02:20] 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 48 was coming out. Now people are using Cloud 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

[02:52] really gotten that much easier, right? Where do you deploy this? Where are you going to run this app? How do you ensure it’s secure, right? How are people going to You want to I’ll 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 going to struggle with, you know, do I put it on Vercel? Well, I don’t have access to a Vercel account or a Cloudflare account because I’m not an engineer. They might not know the details of how to do that. Even for engineers who know how these tools work, they don’t really want to have to go through this and do it from scratch every single time.

[03:25] 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. 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 build a build and ship an application.

[03:56] 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 build a build the thing and make it available. And two, we want a distribution. Right? We want As soon as they ship it, they can link someone else to it. That person can click the link and slack, open it up, and access the application without any red flags or any kind of red tape. And so, we want to move fast. We want to build quickly. We have this applied AI team at WorkOS who’s their kind of singular job is, how do we make AI more and more

[04:28] useful across the company? Not just, you know, how do we move the software development process along, make engineers useful with AI, but how do we make everyone useful with AI? Building, you know, building is cheap, right? We can 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 a sort of a forcing function to gather feedback, which is we’d start doing these company-wide Cloud 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

[05:01] 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, kind of 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

[05:34] helps you build and generate an app without needing to know any of the underlying details. It basically is a toolkit that helps you set up Git, set up a repo, clone in an example application that you can use to start with for Cloud Coder Codex uh to build the app you want to build. And we distribute it to every single employee at the company through our MDM. We just push it on your machine. So, every employee day one has access to this tool. The Well CLI lets you run things like wow app create. What it does is that you

[06:06] name the app, it scans your machine and says, “Okay, do you have get installed? Do you have you logged into GitHub? Do you have Doppler which is your secrets management?” Kind of does all this pre-configuration of your developer machine whether you’re an engineer or not so that everything is kind of ready to go and you’re not going to hit any snags along the way. We also built a shared skills repository. So, anyone at the company can if they 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

[06:36] available, and pull skills down to help you build things or or do certain workflows. So, I’m going to do a quick demo to kind of show you a little bit of what this looks like. Um So, here I’m in this folder and I want to create an app. Let’s do AIE demo. And so, it basically runs through this whole flu- flow. I’ve already obviously configured my machine. It’s not the first time I’m doing this. So, it checks I have get, I have node, GitHub, Doppler, I’m signed in, everything. And

[07:10] what it does actually creates a repo in our enterprise GitHub account. Uh uses a kind of a template that we already have defined. So, it starts out with basically a kind of 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.

[07:45] And we have this internal app example. If it’s not obvious, we’re running this on Cloudflare, um because it makes it really 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?”

[08:21] So, I’m going to let this go off. I don’t know, we’re going to see what it does. Um this is sort of just Claude being Claude, but um I want to walk through like a few parts of uh what we built in some examples of the things we built. So, we have this uh internal registry. So, anytime you push an app with Wow, uh we actually log it into the internal registry. So, you can see we have 278 apps that have been pushed, uh 21 that were had a deployment done today. Uh over the last week, we’ve had 3.3 million requests go through these applications. So, these aren’t just uh

[08:53] little dashboard tools, they’re also APIs, Slack bots, and things that we created and use internally ourselves. Um and then 60 of these are on sort of custom domains, so they have their own uh like branded um domain name. A couple examples of things we built is um Connor on our product marketing team, we send these monthly newsletters that are like, “Hey, what’s the latest in Work OS?” 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 it both Slack and over email, um which is pretty annoying. And so, we built this uh I think my

[09:28] auth. So, here’s how these apps are protected, right? I have to 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 all of our change logs. You can curate that. You can design what the Slack message is going to look like. And so, it’s a kind of singular place to design this experience. I think that I built is we have a change log. Changelog.workable.com/changelog is where we post all our updates. And we

[09:59] do this through Webflow, which is like a CMS platform. It’s pretty 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 got to refresh my auth. There we go. Uh anyone can come in, kind of 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

[10:31] ready, I can post it and then post 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 Cloud Code, build the app that they want, and deploy it live, make it available to the entire company. I’m going to I’m going to 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,

[11:02] “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 want to talk a little bit about Atlas, which is the actual platform underneath this that uh powers 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’s sort of three principles when we’re building Atlas that we wanted to maintain and and that provided a great experience. One was we wanted the infra

[11:33] 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 want to change that to Vercel or AWS, it shouldn’t matter. Should be transparent to anyone trying to build and deploy these applications. Wanted to be secure by default, right? We don’t want to risk there’s 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 of discoverability. Someone shares a link in Slack, anyone should be able to click that and be able to view that tool.

[12:08] So today Ilist runs on Cloudflare’s developer platform. Every app, when you run that wild 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 going to 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 going to be available, how does it get, you know, do

[12:39] people get access? Secure by default. So all of these apps are automatically protected by our Octa SSO account. So you can’t log in if you don’t have access to our Octa account. We’ve actually built for APIs and Slack bots. We 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

[13:10] 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, a problem. It’s all done securely. And then last, we have the catalog for discovery. Every app’s discoverable.

[13:43] 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 60 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. It’s actually becoming um a way in which things are being maintained. We actually had someone build a tool where you take any

[14:13] 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 3 million requests a week run 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 an APIs for that that allows us to access that data in other systems, in Slack. And so, it’s not just humans accessing this data, it’s machines and agents as well. We’ve completely eliminated the need for uh asking for help in deploying

[14:46] 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 60 apps, 37% 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, you know, some engineer, can you migrate this tool? Can you manage this tool on behalf of, you know, marketing

[15:18] or sales?” So, So, more that we want to do here. This is sort of initial version. We want to add granular off. Not every app should necessarily be opened 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 want to support doing kind of like group-based, role-based permissions for these apps easily. We want to add more data integrations. So, we kind of already have this capability aspect to to Wow and to Atlas where if I need access to our Snowflake

[15:48] 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 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 included Slack integration. So, if someone deploys an app, they can also get the Slack app automatically installed.

[16:20] 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. 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 these capabilities to enable anyone in our company to ship internal apps. And if you’re interested in having this kind of capability at your company, I’d

[16:51] love to talk to you about it. Thank you. >> [music] [music]