AI Engineer World's Fair 2025
Building a 10-Person Unicorn
Read the talk
Building a Company That Can Stay Under Ten People
Gumloop’s small-team experiment connects explicit workflow automation with selective hiring, protected engineering time, and a culture built to sustain rapid shipping.
From a talk by Max Brodeur-Urbas
A Series A without a large team
How do you scale a company after raising a Series A without turning it into a large organization? Gumloop had gone through Y Combinator’s Winter 2024 batch and raised its Series A with two founders and no full-time hires, although interns and contractors also contributed. At the time of the talk, Max Brodeur-Urbas reported a team of nine. His public ambition was a ten-person, billion-dollar company—an intended destination, not an achieved valuation.
The ambitious tweet also served a practical recruiting purpose: it attracted people who wanted to work on a small team. Becoming efficient with AI coding tools was only the starting point. The organizational problem was how to turn individual speed into a team that could execute and keep scaling. That required decisions about hiring, daily work, and culture.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Replace open-ended requests with explicit workflows
Gumloop emerged from a sequence of unsuccessful experiments. Brodeur-Urbas built game moderation software, models to estimate children’s ages so adults and children could be separated in VR, and bot detection software. Then, as a side project to those projects, he built a user interface for Auto-GPT. People in its Discord wanted to use AI but did not know how to clone a repository or set it up locally. A simple interface removed that immediate obstacle. He called it AgentHub, imagining a GitHub for agents.
The interface depended on a more fragile assumption: that agents would immediately be useful. Watching users exposed a different opportunity. Their requests were often descriptions of complex but identifiable workflows. Someone who knew Python, API calls, and LLM queries could implement those steps directly, instead of hoping an agent would discover and complete them. The founders changed the configuration model from asking for an entire outcome to defining a sequence of workflow nodes. The user supplied the process; automation carried out its steps.
The company entered YC, brought in two summer interns, and raised a seed round followed by a Series A—roughly four months later in Brodeur-Urbas’s recollection. Capital was intended to make exceptional hiring possible, rather than to maximize headcount. After experience at Amazon and Microsoft, the founders wanted the speed and enjoyment of a small team with fewer meetings. Gumloop became a workflow automation product used by large companies.
The operating practices that followed covered hiring, internal operations, and culture. Brodeur-Urbas presented them as a founder’s developing experience: he could not yet distinguish how much success came from those practices and how much came from repeated good luck. They are an account of one company’s choices, not a demonstrated causal recipe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the hiring bar high, then recruit through the product
Gumloop’s hiring approach combined three practices: selectivity, product-led hiring, and making time to work together. The first was deliberately painful. An Instacart co-founder who had invested in Gumloop reinforced it when Brodeur-Urbas sent over a candidate he considered pretty good: do not lower the bar. The decision needed to be obvious enough that the team was extremely excited about the person.
Brodeur-Urbas reported hundreds of interviews and many work trials. That effort reflected the consequences of each decision: on a very small team, every hire accounts for a substantial share of the company’s capabilities. Remaining selective could also confuse investors who had supplied money to scale. The founders had to be thorough in screening and confident enough to tolerate slow headcount growth.
Product-led hiring supplied a different kind of evidence. Two customers left their jobs to join Gumloop, bringing both enthusiasm and experience applying the product inside a business.
- Enterprise relationships: The customer who originally discovered Gumloop and brought it into Instacart joined to work with enterprise accounts and larger customers.
- Education and community: A former Webflow employee who sold a Zapier course and automation workshops discovered Gumloop, became enthusiastic about it, and joined to lead education and community.
These candidates already understood what the product did and where it was useful.
The recruiting advantage came from that prior experience: the founders did not have to manufacture excitement or explain the company from scratch. But it depended on the product being accessible to people the company would want to hire. A good product could create that channel; whether the right people encountered it still involved luck.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate fit by working together
The third hiring practice moved evaluation into actual collaboration. Gumloop rented Airbnbs for roughly four-day working retreats. Brodeur-Urbas described making three weeks of progress in a couple of days—an anecdotal estimate of concentrated work, not a measured productivity benchmark. At the Yosemite retreat shown during the talk, two participants were candidates on work trials.
Candidates spent several days working as though they had already joined the company. That gave the team concrete experience of collaboration before making a permanent decision. Brodeur-Urbas considered this intentional period together essential to knowing whether someone was a fit. Repeating the process took considerable time, but it increased the founders’ confidence in the people they hired.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Protect engineering time and delegate implementation
Hiring capable people only helped if the company gave them room to build. Gumloop deliberately kept meetings close to zero. The founder’s calendar remained busy with customer conversations and in-person visits, while engineers’ calendars were ideally almost empty. The calendar comparison in the talk makes that division visible: customer-facing work occupied the founder without becoming everyone else’s schedule.
Small teams helped make that possible. A project with several people often needs synchronization and agreement before implementation begins. Reducing that coordination burden preserved uninterrupted building time. Brodeur-Urbas also changed his own role: instead of participating in every aspect of every feature, he wrote rough feature descriptions informed by customer conversations and let engineers determine how to implement them. Trust in hiring became autonomy in execution.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Automate the preparation around customer decisions
Gumloop used its own product to automate internal business work. When an internal task could not be automated, the team built features that made it possible. This connected operational needs to product development: the company encountered automation gaps as a customer of its own software.
Two workflows prepared the founder for customer contact:
| Trigger | Information assembled | Output |
|---|---|---|
| Upcoming meeting | Public customer research and actual product usage | A preparation report covering power-user status and feature adoption |
| Interesting signup | Who signed up and what they were doing in the product | A notification and an email draft in the founder’s inbox |
The signup workflow prepared outreach; it did not remove the founder from the conversation. He could use the draft to reach out, arrange a call, and learn why someone had created a free account.
In Python, the preparation step can be expressed as a small transformation of an already assembled signup record. The output remains a draft for the founder to review:
python
from dataclasses import dataclass
@dataclass(frozen=True)
class Signup:
name: str
email: str
features_used: tuple[str, ...]
def prepare_outreach(signup: Signup) -> dict[str, str]:
activity = ", ".join(signup.features_used) or "No feature usage yet"
return {
"notification": f"{signup.name}: {activity}",
"to": signup.email,
"subject": "What brought you to Gumloop?",
"body": (
f"Hi {signup.name},\n\n"
"I'd love to hear what prompted you to create an account "
"and what you're hoping to automate. "
"Would you be open to a short call?"
),
"status": "draft",
}
signup = Signup("Alex", "alex@example.com", ("workflow builder",))
draft = prepare_outreach(signup)
This example isolates the preparation boundary: activity becomes context and proposed outreach, with no sending operation.
Brodeur-Urbas credited this outreach with substantial growth. Another workflow converted support conversations into product feedback. Brodeur-Urbas reported that the platform’s AI chatbot received about 50,000 messages a day. A Gumloop workflow read chatbot conversations to identify what users found confusing, and the team used those findings to inform product decisions.
He estimated that these kinds of tasks could otherwise occupy a role or consume three to four hours of someone’s day. That was an estimate of displaced work, not a measured time-saving study. Gumloop also had a particular advantage: as an automation company, it could improve the product whenever its own operations exposed a missing capability.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make speed sustainable enough to retain the team
A small team cannot remain exceptional if people are miserable or leave. Yet Gumloop intentionally cultivated urgency. When a customer requested a feature, Brodeur-Urbas often asked, “What if we built it today?” The question spread through the team. Engineers sometimes set a 45-minute timer and tried to ship a feature with Cursor; this was a challenge, not a delivery guarantee.
The same habit could cause burnout. Asking for immediate delivery on a Friday at eight in the evening made the risk especially clear. Brodeur-Urbas paired the emphasis on speed with deliberate efforts to make working together enjoyable. Retreats took place somewhere appealing, with good food and activities such as rock climbing and biking. He saw those shared experiences and future events to anticipate as an offset to the intensity, not evidence that the burnout risk disappeared. The logistics also favored a small company: an Airbnb could comfortably hold ten people in a way it could not hold fifty.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put cultural commitments where candidates can read them
Gumloop wrote its internal statements about company building into a public company handbook. The version shown was already a month or two out of date, and the linked handbook has since evolved. The mechanism was accountability: putting principles on a page gave the team commitments it had to live up to.
The handbook also helped recruit. Candidates could understand the company’s working style before meeting the founders, and Brodeur-Urbas credited it with prompting initial calls and convincing people to join. Public culture made the hiring proposition concrete before an interview began.
The talk closed by applying that recruiting approach directly. After skipping a planned video, Brodeur-Urbas invited applicants and referrals for a founding head of growth to help Gumloop scale. The historical invitation carried both parts of the working proposition he had described: the company aimed to be enjoyable, and the work would be intense.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Gumloop's living handbook covers its origins, hiring principles, customer focus, and working practices. The current edition includes changes since the talk.
The official AutoGPT project repository, with current code and setup guidance for a platform that has evolved since AgentHub's beginnings.
Further reading
- Gumloop's $17m Series AArticle
Max Brodeur-Urbas explains Gumloop's financing, early staffing, and ambition to build a billion-dollar company with ten people.
The early funding announcement describes Gumloop's node-based workflow builder and small founding team.
Gumloop's YC profile retains the founders' explanation of moving from an Auto-GPT wrapper to explicit workflow automation.
Read the complete timestamped transcript
- 0:00
[upbeat music] But, uh, yeah, I'm Max.
- 0:15
I'm the founder of Gumloop. We went through YC a year and a half ago now, Winter '24. So we've been a, a pretty notoriously small team since then. Um, we raised a Series A as a team of two and have...
- 0:28
are now nine people. But, uh, this tweet was kind of like the one that inspired this talk, like how, how we scale to the, uh, the size we hope to be with fewer than ten people.
- 0:39
I'll be honest, I tweeted this when I was extremely caffeinated and, and really thought I was gonna rule the world. [laughing]
- 0:45
Uh, we're on, on track roughly. Uh, we're less than 10 people and growing really fast. But, um, this was also a good Twitter post for hiring because we wanted to hire exceptional people, and I think, uh, working on a small team is really fun.
- 0:57
So, uh, I thought I would go over... I'm sure at th- this conference you've heard a lot about like what AI tools to use and how to work efficiently with Cursor and Windsurf, but I was gonna focus on how you actually...
- 1:07
like once you're efficient with these AI tools, how you build a team that's, uh, has the right culture and can actually scale and do the things you're, you're setting out to do.
- 1:15
But, uh, the first thing I was gonna go over was kind of how we got here. So I spent like six months building up a ton of terrible, terrible software.
- 1:23
Uh, I made like voi- video game moderation software. I made ML models to detect children's age in video games so that you could se- uh, separate adults from children in VR.
- 1:33
I made bot detection software. Um, and then as a side project on top of my side project, I made the first UI for Auto-GPT, which was this like really hyped, uh, open source framework that came out right at the start of the agent craze.
- 1:46
And, uh, I... basically, I noticed that everyone in this Discord was excited to use AI, but they had no idea how to actually clone a GitHub repo or set things up locally.
- 1:56
So I just spun up like a really ugly UI. I called it Agent Hub at the time. My thought was that it was gonna be GitHub for agents. Uh, I, I thought this was really genius.
- 2:04
But it, it was all kind of built upon the, uh, idea that agents were gonna be immediately useful. So we pivoted pretty quickly after this. But, um, I noticed that all of the people who were asking the agent to do things were basically just describing complex workflows.
- 2:18
Like if they knew how to write some Python, they knew how to make some API calls and some LLM queries, they could, uh, basically automate their entire request. They don't need to like cross their fingers and hope that the, the agent will do it for them.
- 2:29
So yeah, that was the realization. It was my co-founder and I at this time. We just started, uh, kind of editing how you could, uh, configure an agent. Instead of asking for everything that you wanted, you could actually define the steps as a series of, of, uh, like nodes in a workflow.
- 2:43
Um, and then we got into YC a few months later. We raised a Series A. Uh, we hired two interns for the summer, and then we raised a serie- or we, yeah, we raised a seed, then we raised a Series A about like four months later.
- 2:55
And, uh, we were just a, a really small team, kind of overfunded, but raised a lot of money so that we could hire the most exceptional people,
- 3:02
um, o- over the next year. And the, the general idea was just scale with under 10 people because we, we noticed after working at Amazon and Microsoft that working on a super small team is really fun.
- 3:11
You can just, uh, move way faster, not sit in meetings all the time. Um, so now Gumloop is this... it used to be way uglier, but it's this, uh, workflow automation tool that a bunch of really large companies are using.
- 3:23
Um, so I thought I could go over how we approach hiring, internal operations, and then team culture. Uh, these are like things that we, we talk a lot about internally, my co-founder and I.
- 3:33
Um, I did wanna put a disclaimer here. I don't actually know what I'm talking about. I, I'm trying to figure out if we're just getting lucky over and over or if like our approaches are actually working.
- 3:42
But take everything I say with a grain of salt because, uh, could be totally off base and it might ruin your company if you do what I do. [laughing]
- 3:51
So the, the three things that we try to do internally when we approach hiring are be super, super picky, which is painful, um, most of the time. Product-led hiring, uh, buzzword that we, we've been trying to coin, and then making time to work together, which I'll explain in a second.
- 4:06
But, um, this is a screenshot from the, the co-founder of Instacart who ended up investing in our company and, and we would ask him for advice 'cause he scaled a large company before, um, running candidates by him.
- 4:16
And, and one time I asked him, like I sent him a candidate that I thought was pretty good. Uh, this was his only reply. He, he tends to write very short emails.
- 4:24
But, um, emphasizing that you shouldn't lower the bar. Like if you aren't extremely excited about someone, like if it's not a no-brainer, you shouldn't even consider hiring them. Uh, so we've done like hundreds of interviews and tons of work trials, which I'll explain in a second.
- 4:36
But if you're gonna be a super small team, every person needs to be absolutely exceptional, um, which m- oftentimes makes like investors of yours like confused because you're still such a small team and they gave you so much money to scale.
- 4:48
But you have to kind of be really, um, uh, thorough with your screening and then also really confident in every single person you hire.
- 4:57
We, we've been trying to coin this term of product-led hiring. So two of our customers ended up quitting their jobs to join the team, and, uh, that was like the...
- 5:04
one of the easiest decisions we've made in terms of hiring because they already loved the product. They had a ton of insight into how it could be used in a business.
- 5:10
So like our customer from Instacart, the one who originally found us and brought us into the company, he ended up quitting and joining us, and now he does a lot of our, uh, like enterprise relationships and working with our larger customers.
- 5:21
And then this screenshot is our head of education and community. He was at Webflow before, but, uh, had a, a Zapier course and a ton of automation, um, workshops that he was selling, and then found Gumloop and got super excited.
- 5:32
So that was a no-brainer. But I think if you can focus on making a really great product that obviously happens to be accessible to people who you wanna hire, um, there's a bit of luck involved there.
- 5:42
But it helps with the hiring process because they know exactly what you do. You don't have to like inspire them to join the team. They, they wanna join on their own.
- 5:50
And then making time to work together. So I think this is only... Hopefully, this video plays.
- 5:57
Uh, yeah, okay. This is only really possible if you have a really small team, but we do this thing where we, uh, rent Airbnbs and we just go hack together for like four days at a time.
- 6:07
We, we make like three weeks of progress in a couple days. But, um, the two people sitting on the left there are actually work trials. Uh, they, they were like interviewing at the time, but we brought them with us to [REDACTED:location] to just hack.
- 6:18
And, uh, I think p- doing this really intentional sort of working together period is the only way you'll actually know if you wanna work with someone. So we always bring people into, into work trials.
- 6:26
They are on the team for several days as if they already joined the company. Um, and then by the end, we're like totally confident whether this is the right fit or not.
- 6:34
And we've done way too many of these, honestly. Uh, but it's helped us make sure that everyone on the team is exceptional.
- 6:42
Um, another thing we try to do in terms of operations, I mean, there's three things here. We have almost no meetings, uh, purposefully so. I try to just let people build.
- 6:52
Like, I hired great people, so my plan is to give them the space to build, which is easier said than done. And then, uh, we automate everything internally, which is kind of a Gumloop self plug.
- 7:01
But yeah, in terms of our calendars, like my calendar is always insane 'cause like we're talking to customers and, or I'm talking to customers and I, I flew back from New York this morning, for example, because I was working with customers in person.
- 7:11
But everyone else's calendar should ideally be totally blank. Um, we try to just give everyone deep focus time. If you're an engineer and, uh, we hired you to build exceptional products, like we, we, we should let you do that, not make you talk about building exceptional product for five hours every day.
- 7:27
I think that's only possible if you have a really small team. Because normally you'll have like five person on... five people on a project. You'll have to sync and kind of agree on the terms before you even start working, and that just leads to, uh, kind of slowness everywhere.
- 7:40
So, um, also letting people build. So, uh, I, I used to be really involved in every aspect of like every feature we shipped, but now that we've hired exceptional people who are all better than I am at basically, basically everything, uh, all I do is kind of like inspire.
- 7:57
I try to inspire what the features we should build are. So I'll, I'll make these like really stupid p- uh, descriptions of the features that I think we should build based on talking to customers, and then I just let people do their thing.
- 8:07
So that, that's kind of like only possible if you hire great people, but once you do, you, you can really just take a, a backseat and give them the space to be exceptional.
- 8:17
And then automate everything you can. So this is our internal Gumloop instance. We, we automate basically every part of the business a- as much as we can, and if there's something we can't automate, then we build features on Gumloop to l- let us automate it.
- 8:28
So like before every meeting, we have like a deep research report that tells us everything we need to know about the customer, not just their outward facing information, but also like how they're currently using our product.
- 8:37
Uh, are they a power user or not? What features are they using? So we- we're like totally informed going into the meeting. Um, we have every time someone interesting signs up, we get notified, uh, uh, why...
- 8:48
what they're doing on the platform and also like a, a email drafted in my inbox, so I can reach out to them, uh, hop on a call and like talk about why they, they have been-- they made that free account.
- 8:57
That's led to a ton of our growth. Um, we have an AI chatbot on the platform, for example, that gets like fifty thousand messages a day. But we have a Gumloop workflow that reads the chats with the chatbot so that it can tell us what people are confused about, and then we use that to inform our product
- 9:10
decisions. So, uh, a lot of these little tasks in the company would have been someone's role or taking up like three or four hours of their day, but now we, we use our own product to automate everything.
- 9:21
So also a lot of luck involved. You can be a small team if you are an automation company, but, uh, if you use Gumloop, maybe you guys could be more efficient.
- 9:29
That's the plug. [audience laughing] All right. Um, so culture-wise, I think this is the most important thing. It's impossible to, to talk about having a really exceptional team, uh, if no one's having a good time or, um, they're quitting.
- 9:42
So, uh, we... I mean, one of the most annoying things I say, uh, at like basically every day when we talk about a feature that a customer's asking for is like, "What if we built it today?
- 9:53
Um, like, what would that look like?" And then it's kind of caught on, and now everyone on the team, I mean, first of all, they're ex-- I've said that like ten times, but they're exceptional and they're really fast-building engineers, so we often just challenge ourselves like, "What if we put on a timer for forty-five minutes and try
- 10:05
to ship this feature, um, right now with Cursor?" Um, but this can lead to crazy burnout. Like, if you're always asking, "What if we did it today?" on a Friday night at eight PM, then people are gonna have a bad time.
- 10:16
So you have to be really intentional about making it fun.
- 10:20
Um, like I mentioned, we do these, these retreats, but we're going, like we're picking a cool place that I wish my like boss would have taken me when I was working at a, a, a company before this.
- 10:31
And then we get a bunch of food and do a bunch of fun things, like we go rock climbing and, and biking and, um, it kind of offsets the intensity of building, uh, with such a kind of like crazy timeline for every feature.
- 10:45
I don't think like anyone would be having fun if we didn't have these like really exciting times to look forward to. I also think this is only possible. You can't fit fifty people in an Airbnb, but you can fit ten pretty comfortably.
- 10:56
Um, and then being really intentional about your company culture is another thing that I'm pretty ademe- adamant about. This is our, our company handbook. It's like a month or two out of date, but, um, basically everything that we say internally, we just put it on a page so that we have to live up to it.
- 11:12
Um, we wanted to kind of hold ourselves accountable for all, all of the, the ways we talk about building a company.
- 11:20
Uh, and this is also like one of the, the things that convinces most of the exceptional people on our team to join or to, to book that initial call because they read our outward-facing handbook, and they know that...
- 11:29
like what we're about before they even meet us.
- 11:33
Um, and I'm kind of at the end of, uh, I was gonna show the video, but cut it a bit short. Um, we are hiring a founding head of growth.
- 11:41
So if you know anyone, you can email me there. Like I mentioned, it's a fun time. Uh, pretty intense, but hopefully
- 11:49
you know someone or you wanna join the team and, and help us scale.
- 11:54
Cool. Okay. [audience applauding] [upbeat music]