Claude Day: What happened when 39 teams let non-engineers drive

Most hackathons start with a blank repo and end with half the teams still fighting their dev environment at lunch. We wanted the opposite. So when we ran Claude Day, a one-day internal hackathon at WorkOS, we set two rules that flipped the usual format on its head.

Rule one: the non-technical teammate drives. Rule two: nobody spends the morning installing dependencies.

Here's what we built, what we shipped to make it possible, and what we learned watching 39 teams ship internal tools in a single day.

The premise

Claude Day paired everyone into 39 teams of mostly two people: one developer or software engineer, one less-technical teammate, and an AI engineer. Teams were matched by time zone, office location, and department where possible, so people would actually know each other and be working on problems they shared.

The goal was simple: get everyone building internal tools with AI, and walk away with something that made improved their day-to-day. Everyone demoed the day after.

The twist that mattered most: instead of pitching ideas and forming teams around them, each person chose a problem from their own actual work, and the engineer came along to support their vision. We told the engineers ahead of time, in plain terms: your job is to unblock, not to take over. The non-engineer holds the keyboard, or at least holds the steering wheel on Claude.

That single constraint changed the energy of the day. The person closest to the problem was the person making the decisions.

‍

Killing setup time

The single biggest risk in any hackathon, especially one where half the participants aren't developers, is that people spend the morning fighting their machine instead of building. So the applied AI team pre-built a lot of the scaffolding.

The centerpiece was a CLI tool called wow, named after our company value "earn the wow". Iru pushed it to everyone's machines automatically, so nobody had to install it themselves.

One command installed everything you needed. A second command, wow app create, copied over a pre-built example repo, renamed the app automatically so it worked with Cloudflare out of the box, and wired up a GitHub Action along with the necessary GitHub secrets.

The very first git push deployed a live app at their-app-name.workos.tools. That app already had a Cloudflare Workers backend, a D1 database, R2 for images, and zero-trust auth baked in.

Read that again: every participant had a real, deployed, authenticated app on a real URL before they wrote a single line of their own code or started a single chat with Claude.

For teams building Slack bots (which turned out to be a lot of teams) there was wow app add slack. One command scaffolded all the keys and configuration needed to get a Slack bot running, so nobody had to figure out the Slack API setup from scratch.

We also pre-provisioned secrets (API keys, tokens, the usual suspects) so nobody had to file a ticket to get into Notion or Snowflake. They just had what they needed from the start.

All this scaffolding existed to compress the distance between "I have an idea" and "I'm iterating on a working app." When the floor is that high, the ceiling moves up with it.

What 39 teams built in a day

The project list was the best part of the day. Almost every team picked something they had personally been annoyed by for months.

A few highlights:

• Broadcasts: Pick your audience with filters, send Slack messages, then track delivery, reactions, replies, and link clicks per channel.
• Customer Command Center: A dashboard surfacing customer activity teams can follow up on.
• Company-wide WorkOS interaction view: A comprehensive overview of every interaction a company has had with WorkOS across product, marketing, events, sales, and support.
• AuthKit branding preview: An app that lets users preview their branding assets in AuthKit before creating an account.
• Marketing asset generator: A tool that generates marketing assets for product features.
• Figma design spec extractor: An easy way to extract all design specs from vendors and set up frames in Figma.
• Conference targeting list generator: A tool that consolidates the multi-step manual process to generate a target outreach and gifting list for any given conference.
• Onsite planning tool: All the logistics that make a team onsite actually work: flight tracking, restaurant suggestions, agenda building, and everything in between, in one place.
• Laptop provisioning automation: An internal app to automate how Operations gets a laptop into everyone's hands.
• Inspiration board: A visualized and categorized inspiration board pulling from a Slack inspiration channel.
• Docs gap finder: A tool that surfaces documentation gaps.
• And so much more!

Other teams shipped projects worth talking about across product, engineering, sales, marketing, and operations.

The pattern across the list: nothing here is a toy. Most of these are tools that plug directly into how we actually work.

What people learned

We asked teams what they took away. A few themes came up over and over.

• ‍You learn the stack by needing the stack. People picked up real, concrete details: the difference between Slack bot tokens and user tokens, how to add AuthKit and Pipes to an application, and the importance of saving work and pushing code to the repository. Nobody learned this from a tutorial. They learned it because their app didn't work until they understood it.‍
• Claude is a different tool depending on how you use it. Teams came away with a clearer sense of what Claude can do when wired into GitHub and databases. One person landed on a workflow of using Claude to design, then chat (for prompt building and deepening understanding), then code for execution, and found it effective, even though the interaction wasn't as deep as expected. Other teams learned about coding itself, about how AI is changing it, and how to think about the flow of information through a system.‍
• Sometimes the bot is wrong, and that's okay. One respondent had a small but important realization: repeatedly prompting the bot isn't always a sign that you don't know what you're doing — and reading the documentation can resolve issues even when you're working with an AI. That's a healthy instinct to build early.‍
• Agents speed things up, but only once you're in. Multiple teams reported that working with agents accelerated their work. The catch is getting past the first wall.
  ‍

Advice from the people who'd never built an app before

The most useful output of the day might be the advice from non-engineers to other non-engineers about to do this for the first time.

• ‍Be patient. Be persistent. Try things. New builders should be patient, persistent, and not afraid to try, knowing the payoff is worth the initial effort. When you're stuck on a complex feature, persistence is the move, sometimes that looks like asking the AI the same question over and over with slight tweaks until something clicks.‍
• Reframe what you're doing. Don't call it "coding." Call it self-serve building your own tools. It feels more approachable, because it is more approachable.‍
• Pick one workflow. It's tempting to scope a hackathon project like a real product. Don't. Narrow down to one workflow, there are a lot of features that masquerade as P0 tasks but aren't.‍
• Use the AI as your translator. Ask Claude to explain things as non-technically as possible. Read the documentation. Be willing to ask questions.‍
• Just start. The single most important step is to start, because the project gets easier once it's in motion. The hardest part is the blank screen; once something is running, every next step is just a small edit to a thing that already exists.

The takeaway

Claude Day worked because we made two bets and stuck with them: put the non-engineer in the driver's seat, and remove every piece of setup friction we could think of before the day began. The combination is what made the difference. Either one on its own would have produced a familiar kind of hackathon. Together, they produced 39 real tools and a company full of people who now know they can build their own.

If you're thinking about running something like this internally, that's the whole recipe. Pre-build the scaffolding so the first git push ships a working app. Pair people across the technical divide. And then get out of the way.