Starting a Company in 72 Hours With Grokbot AI Bots

You do not have a company yet. You have menial work, a blank repo, and a clock. That is the starting line Matt Palmer, Lauren, and Roshan set: 72 hours, no idea chosen, brand-new Grokbot accounts with zero bots, and a public push to ship something useful enough that a human will pay for it.

The method is not “add AI to the to-do list.” It is to run Grokbot as workforce and operating system — research the idea, hire bots the way you would hire a founding team, use Slack as the control plane, and keep people on the work that still needs a person.

If you have never opened Grokbot, you can still execute the sequence. If you already use it for personal automation, this is the tighter company-building version of the same stack.

Key takeaways

• In this playbook, a company means something useful people want, that you would dogfood, that puts dollars in a bank account, and that serves a human — even if an agent places the order.
• Start from a true blank slate: a new Grokbot team, empty bot lists, and a dedicated GitHub org, not leftover work tools.
• Lock an idea on day one. Run Grokbot over the pile of idea submissions before anyone writes product code.
• Hire bots on purpose: founding engineer, intern, designer, marketing, plus an onboarding factory that reads a company doc and spins up employees.
• Stand up Slack first. An issues channel can feed a factory that opens PRs instead of tickets. Notion is for notes. Linear is optional until you actually have a backlog.
• Use Cursor to write code. Use Grokbot for the slow human work: market research, selling, coordination, and creating other bots.
• Search the Grokbot marketplace for P-stack if you want Lauren’s engineering workflows. She describes it as open source and costing nothing.
• Provision tokens early. Plan for payments (a Stripe/Link card a bot can hold) and add a database only when the product needs one.

Who this is for — and who should skip it

This is for a founder, operator, marketer, PM, or engineer who will install Grokbot and work in a small team with Slack, Notion, GitHub, and Cursor. The speakers assume mixed skills — engineering, product, and GTM — not a pure research lab. Grokbot has a free trial; they treat installing it as the one required first step.

Skip it if you need a finished business idea, copy-paste prompts, or a path that does not use Grokbot. This session is the kickoff plan, not a completed build. Skip it if you will not create a Grokbot account or will not let bots into Slack and GitHub.

What “a company in 72 hours” actually means

Online, “building a business” gets inflated into startup, billion-dollar outcome, or even “build SpaceX.” The team already works at SpaceX. They defined a much smaller, sharper bar.

Matt’s frame is build something people want — useful, something the team would use themselves, so they have empathy for the customer. Lauren adds dogfooding: the loop she likes on Grokbot is using the product to improve the product. She also insists it is not a real business until money hits a bank account. Roshan wants zero-to-one work: find data for what to build, listen to what the world is saying, run user research, and coordinate designer and marketing bots instead of only extending an existing platform.

AI frees you up to do the stuff you actually care about.

Matt’s other constraint: a business serves humans. Agents may buy, but a person asked the agent. A t-shirt shipped to a door, coffee beans delivered, or Grokbot itself — each is a human experience. The goal is to make someone happy enough to pay and come back. He also wanted, if possible, a digital thing that shows up in the physical world, especially with tens of thousands of people in San Francisco for Dreamforce. That physical piece is a wish, not a promise. They did not yet know if 72 hours could support it.

What it means to build a business is ultimately to serve humans.

What “good” looks like at this stage is not a valuation. It is a shared definition: useful, dogfoodable, paid, human. If you skip this conversation, you will hire bots to optimize the wrong object.

Set up a blank-slate Grokbot team first

You are trying to create a separate entity, not a side channel in your day job. The team did almost no prep. That is the point: you should be able to start from nothing.

What to prepare

• Grokbot installed, with a free trial if you are new.
• A new Grokbot team used only for this company.
• A blank GitHub org. Theirs was named Ship by Thursday (github.com/shipbythursday) and had no repos.
• Slack as the first control plane, including an issues channel.
• A Notion space for notes and the company doc.
• Tokens. They called this central, not optional.
• Cursor for code. P-stack from the Grokbot marketplace for engineering defaults.
• Later: Stripe/Link for payments, a database when you need infra, Linear only if a backlog appears.

Steps

1. Download Grokbot. Matt’s line: if you are starting a company, that is really the only prerequisite.
2. Create a dedicated Grokbot team. Give each founder their own bot teams so you can switch context and, if you want, let outsiders interact with specific bots.
3. Create a dedicated GitHub org. Do not dump this work into an existing company org.
4. Open Slack first, then Notion. Treat Slack as the place humans and bots talk. Add an issues channel and wire a “factory” to it so reported bugs can become fixes.
5. Install P-stack from the Grokbot marketplace (search “P-stack”) before a mixed team starts committing. Lauren built it so PMs and designers can contribute and still get good defaults.
6. Hold Linear. Lauren’s bias: if people report bugs while using the product, auto-fix them. Tickets are for a backlog you cannot clear in the moment.
7. Assume you will need payments and a database, but do not block idea work on picking a database vendor.

Good setup looks boring: empty org, empty bot list, Slack you actually live in, tokens available, P-stack installed. Failure looks like debating Linear, whiteboards, and coffee while the 72 hours burn. They said this out loud — talking instead of building is the first leak.

Use Grokbot for market research on day one

The hard manual part of starting is not syntax. It is deciding what to sell. They already asked viewers and SpaceX employees for ideas and had thousands of responses. The first build step is not a repo. It is Grokbot over that pile.

What to prepare

• A raw dump of idea submissions, comments, and internal suggestions.
• Marketplace user-research bots or templates, which Roshan already uses.
• Willingness to throw away prototypes. Matt’s pattern: bots that spin up a quick visualization of an idea so you can see it, not just rank it.

Steps

1. Collect ideas in one place. Do not pre-filter for “serious.”
2. Ask Grokbot to read the responses and do the market research pass: what people asked for, what repeats, what you would use yourselves.
3. Pull user-research bots from the Grokbot marketplace if you need interviews, not just a summary of comments.
4. Optionally have bots produce throwaway prototypes so ideas become screens, not slogans.
5. Pick the idea on day one. With three days total, they treated a same-day decision as the plan, then announce it.

Good output is a shortlist you would dogfood, not a slide of TAM. Failure is coding a stack before the idea exists, or treating X chatter as the only customer because you are terminally online. Matt’s warning: X is where people go to know things, and it is a biased room. The business still has to work for a human who may never post.

Hire bots the way you hire a founding team

Other Grokbots can create Grokbots. The team wanted to use that instead of a vague “we’ll automate later.” Think onboarding, not plugins.

Matt’s org-chart version: write a company doc that states who you are, the principles, and the current state of the company. Build an onboarding / factory bot that reads that doc and creates employees. Hire an intern bot, a founding engineer bot, and later designer and marketing bots. As the company changes, bots update the state — or every bot is responsible for updating it.

Lauren’s version is more mechanical: wire the factory to the Slack issues channel and turn reports into PRs. Roshan’s version is product-shaped: research bots, then design and marketing bots once there is something to ship.

Use case	Bot / tool	Input needed	Output	Owner
Market research	Grokbot	Idea submissions from audience and employees	Synthesis of what to build	Whole team
User research	Marketplace research bots	Research goals, people to talk to	Interviews and insight for zero-to-one	Product (Roshan)
Tech scouting	Grokbot + Cursor cloud agent	X bookmarks of packages and tools	A deployed preview and a morning message	Matt Palmer
X auto-reply	Grokbot	A trigger phrase in mentions	Replies at a volume a human cannot sustain	Lauren
Issue-to-fix factory	Grokbot + Slack issues channel	Bug reports while using the product	PRs / fixes, possibly straight to main	Engineering
Hiring / onboarding	Factory Grokbot	Company doc (principles, process, state)	New employee bots that know the company	Whole team
Payments experiment	Grokbot + Stripe/Link card	A linked card on a bot	A human or another bot can buy	TBD with the idea

Two patterns already in production on the team

Matt’s favorite recent demo: a Grokbot watches his X bookmarks for a package or technology he saved, starts a Cursor cloud agent to build with it, and uses a repo configured (also via Grokbot) for preview deploys — he thought via Cloudflare. Every morning he gets a message: here is the thing you bookmarked, and here is a deployed version. That is the prototype muscle they wanted for other people’s ideas.

Lauren automated a joke. If you summon her on X by repeating “potato,” a Grokbot replies, because she cannot answer that volume by hand. The company lesson is the same: if a role is real and repetitive, it is a bot, not a hero queue.

Good hiring looks like named roles, a company doc the factory can read, and bots that show up in Slack. Failure looks like one mega-bot that “does GTM and engineering,” or creating bots with no onboarding so they do not know what the company is.

Run Slack as the control plane and ship

Once the idea exists, the build stack is ordinary on purpose. Three people with laptops would still need a place to talk, a place to take notes, and a place to ship. They chose Slack, Notion, Cursor, Grokbot, and GitHub. Guests and other SpaceX AI people can advise; the people at the keyboards still ship.

Engineering defaults

Lauren’s P-stack is an open-source Grokbot marketplace plugin that packages the skills and workflows she uses for rigorous engineering. She said she shipped about 2,500 PRs of P-stack into production in a month and hoped she caused no bugs. Matt did the napkin math: that is about 83 PRs a day. For a three-day company they joked about a PR meter, then Lauren said she might skip PRs and merge to main — a commit meter instead. Treat that as her bias toward speed, not a policy you copy blindly. The rest of the team’s reaction on stream was “oh boy.”

Why open an issue when you can open a PR?

Use P-stack so non-engineers can contribute and the repo stays coherent. Use the issues channel as an intake hose, not a shrine for tickets. Open-source Easter eggs in the public org if you want people to follow along — they floated that, then admitted the org was still empty.

Money, buyers, and infra

They want dollars in the account inside the window. Grokbot can hold a linked Stripe/Link card, so a human or another bot might buy. That could mean a product people purchase, or a thing other people’s bots purchase. Do not wait for perfect payments architecture; do decide whether the first SKU is digital, physical, or in-person.

Infra comes last: a database when the product needs state, friends who know databases if you need help, a whiteboard when the design has to leave chat. Tokens are not infra in that sense. They are fuel. Budget them like you would budget founder time.

Good shipping looks like commits in the empty org, a product the team is already using, and a path for someone to pay. Failure looks like a beautiful stack and no SKU, or a bot storefront with no human reason to care.

How they think about time, quality, and money

They did not give time-saved percentages, support-load cuts, or lead counts for this company. They had not started building it yet. The checkpoints they did name are qualitative, plus one engineering anecdote from other work.

• Time: AI should take Excel archaeology, lost messages, boilerplate coding, slides, and design grunt work off the calendar so you spend the 72 hours on judgment and customers.
• Day-one quality: an idea you would use yourselves, informed by Grokbot over real submissions, not a vibe.
• Throughput: Lauren’s P-stack story is 2,500 production PRs in a month on Grokbot itself. That is her claim about that workflow, not a forecast for your first week.
• Handoffs: Slack between humans and bots; factory output as PRs; company state updated in the doc so new bots onboard without a meeting.
• Money: dollars in a bank account. A Linked card on a bot is a means, not the business.

If you need a single scoreboard for the week, use theirs: idea locked, bots hired against a company doc, something a human (or a bot acting for a human) can buy, and you are dogfooding it.

Pitfalls and where humans stay in the loop

• Talking away the window. They burned opening time on intros and still had no idea. Research and hiring have to start before the stack feels complete.
• Building before the idea. Day one is for Grokbot on the submissions. Code follows the choice.
• Serving agents and forgetting people. A bot can buy. A person still has to want the thing.
• Ticket theater. If the product can report a bug and a factory can open a PR, a Linear board may be delay dressed up as process.
• Merge-to-main bravado. Speed is the point; unreviewed main is how you get the “oh boy” look from your own teammates. P-stack exists because defaults matter when everyone can commit.
• Starving the run of tokens. They called this out as easy to forget and essential.
• Infra cosplay. Database CEOs, chalkboards, and payment diagrams are not the first hour. Slack, Grokbot, GitHub, and an idea are.
• Assuming the physical stunt will fit. Manifesting something in the real world for a conference crowd is a goal Matt wanted, not a commitment they could already defend.
• Expecting a clean demo. They promised mistakes, mess, and stretches of silent typing. That is the working mode, not a failure of the method.

Humans stay on definition (what “company” means), idea choice, taste, customer conversations, and anything that puts money or brand in front of a real person. Bots stay on research crunching, scaffolding, replies at volume, prototypes, and turning issues into code.

A 7-day plan to run the same sequence

They had 72 hours. If you are not live-streaming from a studio, stretch the same spine across a week. Do not add a generic sprint on top of it.

Day 1

Install Grokbot. Create the isolated team and the blank GitHub org. Open Slack (with an issues channel) and Notion. Dump every idea you already have — audience, customers, coworkers — into one place. Start the company doc: who you are, principles, what you are trying to do. Provision tokens.

Days 2–3

Run Grokbot over the idea pile. Pull marketplace research bots if you need interviews. Build one or two throwaway prototypes so the shortlist is visible. Lock the idea. Hire the factory bot plus founding engineer and intern bots against the company doc. Install P-stack. Decide digital vs physical enough to know whether you need a Stripe/Link card on a bot this week.

Days 4–5

Build in Cursor with Grokbot on the manual work. Wire the issues channel to the factory. Dogfood whatever exists. Add payments when there is something to buy. Add a database only if the product needs one. Keep Linear closed unless a real backlog appears.

Days 6–7

Ship something a human can use and pay for. Update the company state so every new bot reads the same reality. Open-source only what you want followed. If you still want a physical manifestation, make it a thin extension of the digital SKU, not a second company. Stop adding roles. Sell the thing.

The 72-hour version compresses days 1–5 into three calendar days and uses days 6–7 only if you are not on their clock. The order does not change.

The outcome is not a mythic startup. It is a useful product, a bot-shaped team that can keep shipping, and a human who is happy enough to pay. Install Grokbot, stand up one dedicated team, and write the company doc the factory will use to hire the first bot.

FAQ

Do I need Grokbot to run this playbook?

Yes. The team’s stack is Grokbot-first: a new team, marketplace templates, bots that create other bots, and a factory in Slack. They pointed new people at a free trial and said installing Grokbot is the actual prerequisite for starting. If you will not use it, you are not running this method.

Grokbot vs Cursor — which one builds the company?

Both. They use Cursor to write code and Grokbot for the work that usually stalls a three-person company: idea research, selling, coordination, onboarding, and spinning up more bots. Matt’s bookmark demo even has Grokbot launch a Cursor cloud agent. Treat Cursor as the editor and Grokbot as the rest of the company.

Do I need Linear if Slack is the control plane?

Not at the start. They named Linear as something they might try for tickets, then Lauren challenged it: if usage reports bugs and a factory can open a PR, a ticket is extra. Start with Slack and an issues channel. Add Linear only when you have a backlog you cannot clear by shipping.

What is P-stack, and do I have to use it?

P-stack is Lauren’s open-source Grokbot marketplace plugin. It packages the skills and workflows she uses for engineering so other people — including PMs and designers — can contribute with good defaults. She said it costs nothing. You do not have to use it, but they planned to install it before a mixed team started moving fast on an empty org.

Can a Grokbot take a credit card and buy things?

The speakers said you can give a bot a credit card now by linking a Stripe/Link card. They wanted to play with humans buying, bots buying, or both. That is an experiment they were excited about, not a full payments runbook. The business still has to be something a person wants.

Is 72 hours enough to make a “real” company?

By their definition, yes if you ship something useful people want, dogfood it, and get dollars in a bank account. It is not enough if “company” means a scaled startup or a rocket lab. They were explicit that internet commentary was inflating the brief. Day one is the idea; the rest is a thin, paid product.

Should the first product be digital or physical?

They did not choose. Options on the table included a digital product, something like coffee beans delivered, an in-person experience, or a digital thing that manifests in the real world during a busy week in San Francisco. Matt favored a digital-to-physical path. Treat that as a preference to test against the research pile, not as the answer.

How do you hire a bot instead of a person?

Write a company doc covering identity, principles, and current state. Use a factory Grokbot that reads the doc and creates employee bots — intern, founding engineer, later design and marketing. Have bots update the company state as you go. Other Grokbots can create Grokbots; onboarding is the control, not a one-off prompt in chat.