How we built Grok Bot in a month | Roman Ugarte (SpaceXAI)

What It Covers

Roman Ugarte, product lead at SpaceX AI, details how a small team built GrokBot — a cloud-based AI teammate product — in one month from first line of code to internal beta, then launched publicly three weeks later. The episode covers the two foundational decisions, manual onboarding strategy, and the "colleague-pilled" product philosophy driving GrokBot's rapid adoption.

Key Questions Answered

• •Start fresh vs. extend existing products: GrokBot succeeded partly because the team rejected adding knowledge-work features into Cursor and instead built a standalone product from scratch. Competitors who added new tabs to existing surfaces created cluttered experiences that users reacted against. A clean slate allowed every pixel to serve a single, consistent vision — a lesson applicable to any team debating whether to extend or rebuild.
• •Small, isolated teams move faster on novel products: The GrokBot prototype went from zero to functional in roughly one month with a handful of people working in a physically separate office space with private Slack channels. Larger groups debating six-to-twelve month roadmaps would not have reached the same outcome. For novel product bets, deliberately constrain team size and cut communication surface area to accelerate micro-decisions.
• •Manual onboarding of 200–300 early users surfaces blind spots faster than any dashboard: The core team personally onboarded several hundred users over two weeks, including non-obvious profiles like a coffee shop owner. Painful early sessions drove next-day fixes. Crucially, the team avoided leading users toward specific patterns — like the "chief of staff bot" hierarchy — to validate whether those behaviors emerged organically before encoding them into the product.
• •Cloud-native, persistent bots with their own computers are the core architectural differentiator: GrokBot runs entirely in the cloud, meaning bots maintain consistent state across devices, can be triggered from a phone, and operate independently of the user's machine. Each bot also has its own virtual computer for browser-level interaction, enabling tasks that lack MCP or API support. This mirrors how human colleagues work — on their own laptops, not sharing yours.
• •Frame capabilities as "GrokBot can now" not "GrokBot now has": The team uses this linguistic test to filter roadmap decisions. Features that add UI elements without expanding what bots can actually accomplish get cut. Automations, for example, are defined entirely in natural language — telling a bot "remind me at 8AM daily" creates the routine without any dropdown menus. This framing forces the team to think in terms of bot capability, not product surface area.
• •"Delete the product" and "just do the thing" as operating values: Two explicit cultural principles govern execution speed. The first pushes teams to remove scaffolding built around model limitations as models improve, even when it upsets some users. The second eliminates permission-seeking — anyone who identifies a problem is expected to fix it and pull in resources independently. Both values together allow significant product reinvention on cycles shorter than six months.