The short version: Crema's whole team spent a day and a half building internal tools with Claude, in teams of two or more. AI made the building fast, which moved the hard parts onto people: agreeing on what to build, reviewing each other's work, sharing access, and knowing what already exists. The eight lessons below cover what slowed teams down and what helped.
It’s now possible for one person to feasibly design, build, and ship a working app in a day. At a lot of companies, that's exactly what's happening. There’s the audacious exec who builds a tool over the weekend and wants to push it to production on Monday. Or the tinkering product manager who is ready to take matters into their own hands. It's faster, but it means everyone is working from their own ideas, which means bringing anyone else in later gets harder.
Crema spent a day and a half testing a more social path. Our entire team stepped away from client work for one and a half days to build internal tools with Claude, together! The goal was to have this new tooling bring folks together in accessibility, function, and data.
Accessibility means anyone at the company can reach the tool, run it, and contribute to it. Function means the tool is built as a shared effort and works for more than the person who made it. Data means the tool draws from, and adds to, what the whole team knows.
These were the ground rules:
- Build in teams of at least two
- Build something that helps the company or a client
- Deploy it behind a sign-in where everyone can reach it
- Leave a repo someone else can pick up.
Here are the eight biggest lessons from the experiment.
What did the teams build in a day and a half?
Five teams demoed on Friday morning. Some started totally from scratch, and some picked up a tool one person had already been building alone.
- Growth Hub: A shared home for the growth team's events, content calendar, brand assets, photos, and priorities, where anyone at Crema can drop in a link or an idea.
- The Crema Brain: An internal knowledge base, moved from Notion into Markdown files in GitHub, now with tasks, single sign-on, and a new design.
- AI Brew Guide: Pulls in AI news every night and turns it into a glossary of more than 1,000 terms, a set of learning modules, and a map of how AI systems work.
- PDLC: Maps every activity in Crema's product development lifecycle and how much AI is involved in each one, so teams can test moving work from one tier to another. Short for Product Development Lifecycle.
- Launchpad: A registry of every internal app Crema builds, with a Claude plugin that checks whether something already exists before you start building it.
What did we learn about team AI collaboration?
1. People became the bottleneck once building got fast
Two engineers predicted this on the first morning, and by the end of the day it was the most common answer in the room. One described it as drinking from 10 fire hoses at once and summed it up as “people are the problem.” A product director said that even moving as quickly as her team did, she felt like she was blocking somebody at every moment. None of this is new to anyone who has worked on a product team. The difference is how much more of the day it takes up once the building itself gets fast.
2. A tool built mostly by one person was hard for others to pick up
One product was about 90% built before the hackathon, by one person working on their own. When two others joined, the parts they had assumed were simple turned out to be the hardest for others to follow. The stated takeaway was that going rogue on an isolated project for too long can create something that works but is almost impossible for anyone else to pick up. Knowing how fast you can move alone makes you want to skip the collaboration, but the cost shows up the first time someone else has to work on what you built.
3. Sign-in, access, and permissions slowed nearly every team
The Growth Hub team found that Crema's Google Cloud account held 75 Google OAuth instances (the app registrations that let a tool offer "Sign in with Google"), hidden behind a tab nobody clicks, which explained why people couldn't see each other's work. They also learned Google won't approve an app's branded sign-in until it has a homepage explaining what the app is for. On the Brain, single sign-on (one company login that works across apps) alone wasn't enough, because 7 of the 24 company email addresses belong to contractors or people who have left. Access now runs off sign-on plus an approved list.
The Launchpad engineers spent stretches of the day waiting on authentication, two-factor prompts, and GitHub token scopes. The PDLC board ended up with two versions of the same person because sign-on arrived halfway through the build. In the end-of-day review, people described passing keys back and forth over Slack and asked whether a product team now needs a system administrator on it.
AI makes it feel like you don't have to be a developer, but collaborating on code still means learning GitHub, deciding where to host, and handling environment variables securely. One product manager said coding wasn't as scary as she expected. The new part for her was contributing to a shared app, with pull requests someone else had to approve.
4. Most teams spent their first hour deciding what to leave out
AI lets you build quickly, but a team still has to agree on what it's building. The PDLC team spent its first hour defining what it wanted to finish that day. The Launchpad engineers started planning for edge cases far in the future, then pulled back to what they could ship that afternoon. Their goal was that by noon, someone could open the app and complete a specific set of tasks.
The Brain team felt the same pull between what was critical that day and the bigger ideas the day's work would open up. One developer said a single giant plan, kicked off all at once, would have been hard to test and even harder to judge. Starting with a simple app registry gave the team something to build on. Another said that once building gets easier, the hard thinking shifts to what you're building and why, and writing good user stories is still a human job.
One person has Claude write a design spec and an implementation plan before building anything from the backlog. It takes longer, but the result lands closer to what he wanted, and it leaves a written trail anyone can follow later.
5. Every change still went through a second person's review
Crema's policy is that a second person reviews every change. One builder ran two adversarial reviews on their own pull request before sending it to the engineers. They weren't sure what was reasonable to ask a reviewer for, or how long a review should take. Working alone at home, they'd have just pushed their changes through. They said the extra step slowed them down, and that was a good thing.
The exec's weekend-built tool shouldn't ship on Monday for the same reason. A second set of eyes is how a team catches security issues, stays compliant, and makes sure it built the right thing for the right users.
6. The teams that split the work by discipline got the furthest
The Brain team ran discovery together and then split up. The designer took the design system, information architecture, and navigation. Her teammate took the database, the move to Vercel, and single sign-on. Her designs in Claude became the spec he built from, and he said it felt like they'd done a full engagement in one day.
They also didn't let old assumptions set the limit. Claude estimated single sign-on would take two days, and the team had it working the same day. One developer's advice for anyone trying this is to come in with roles defined, so everyone knows who makes which decisions before the plan starts to sprawl.
7. We had to build a copywriting skill so the AI-written copy wasn't all slop
The AI Brew Guide team found that the learning modules all sounded like Claude. They were written from the technology's point of view, with lines like "a model keeps nothing between calls," which you can't read if you don't know what a call is. The team built a Crema copywriting skill and used it to rewrite the lessons module by module, approving each before and after. By the third module, they knew what they didn't like and let it run through the rest.
One product manager spent her whole day reducing noise on the PDLC board, which tracks about 190 activities. One screen had a dropdown of every activity with no context about where any of them lived, so she replaced it with a map. She added a getting-started card and a simpler reference view for people who only need to look things up. A tool the team doesn't understand in the first minute is a tool they won't come back to.
8. A shared knowledge base gives everyone's AI the same starting point
The Brain started in Notion. As the team leaned harder on AI agents, Notion stopped fitting the way they worked. The information architecture wasn't right, and getting agents to write back to it reliably never quite worked. So the team moved it into Markdown files in a GitHub repo, with a site in front of it for people who'd rather not touch GitHub.
The hardest part is the habit people carry over from older knowledge bases. With the Brain, anyone can point Claude at the repo, ask a question, and get an answer drawn from everything the team knows. Each person's AI starts from the same shared context instead of whatever they remember to paste in. Launchpad applies the same idea to apps. Most companies have teams building internal tools that do slightly different versions of the same thing, and nobody finds out until the work is done twice. Launchpad's Claude plugin is on by default for everyone at Crema, and when someone asks Claude to build a new app, it checks Launchpad first and asks whether they'd like to contribute to the one that already exists.
How do you make time for a team-wide hackathon?
There's never a good time to step away from day-to-day work. One VP said the hackathon was the first time he could pull someone in to help him think without worrying he was pulling them off a client priority, and the first time in his career he'd had a whole day to focus on one project.
The advice for other teams is to commit to blocking out the time, set aside both client and internal work, and use the days before to generate ideas so you can start fast. Crema's leadership called it a forcing mechanism, since the shared momentum only happens when everyone steps away at once. Another VP estimated that what the team built would have taken six months working the old way.
What should teams adopting AI together do first?
AI made the building fast, and that moved nearly all of the hard parts onto people: getting aligned, reviewing each other's work, sharing access, and knowing what already exists. Working alone with AI is still faster at the moment. Crema is choosing the more social path on purpose, because the solo version costs more later. That cost shows up the first time someone else has to use, maintain, or build on what one person made.
For any team figuring out how to adopt AI together, the hackathon points to a handful of practical moves. Block the time for everyone at once, decide what to leave out before anyone builds, keep the review step, sort out sign-in and access early, and point everyone's AI at the same shared knowledge. It's the same cross-functional discipline good product teams have always relied on, applied to tools that now make it easy for any one person to skip it.
