Building a 10-Person Unicorn

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.

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.

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.

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 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.

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.

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:

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:

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.

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.

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.