Grok Bot Software Factory: Engineer Workflow Playbook

Starting a company is not one job. You have to pick an idea, ship a product, go to market, charge money, and then keep the thing alive when feedback and bugs show up. A lot of people hope a model will skip that stack. The team that spent three days trying to build a business with Grok Bot found the opposite: bots get fast after a human has already discovered the work.

If you want to build a business with Grok Bot, the usable method is narrow. Align on an idea you already understand and that other people actually get excited about. Ship a small MVP. Cut features until only the core loop is left. Then hire a varied team of bots the way you would hire people — and only automate a workflow once you have felt the problem yourself.

What follows is the operating manual: who should try this, how to staff the bots, how to run a feedback-to-fix factory, where humans stay in the loop, and what to do in the first week.

Key takeaways

Ship as soon as the team is aligned and excited. Deliberating the idea is what made this group slow; the MVP is what made them fast.
Build around work you already know how to do. Domain ignorance does not disappear because you have agents.
Discover problems as a human first. Once you know how to solve them, turn that solution into a bot and leave it running.
Staff bots like employees: a chief of staff, a data bot, game-design bots, a bot that creates other bots, playtesters, and a factory that turns feedback into fixes.
Give bots dense context — best-in-class examples, courses, rules pages, and in-flight work — instead of one-line tasks.
Exercise restraint. Abundance of build capacity is how you get a million features and a product that is not good. Unship on purpose.
Keep two human jobs: clear vision and taste for what belongs in the product, and someone relentless at making things happen.
Full autopilot on merges can ship fixes all day. It can also take production down. Treat YOLO as a choice with a rollback plan, not a default.

Who this is for (and who should skip it)

This is for a founder, operator, marketer, or ops lead who already has a domain — a game, a workflow, a product surface — and wants Grok Bot to accelerate shipping, feedback, and the unglamorous maintenance work. The stack the team actually used assumes Grok Bot, Slack channels, GitHub pull requests, Cursor cloud agents, and the willingness to glue existing products rather than rebuild auth, database, hosting, and payments.

Skip it if your plan is “prompt the models to make a billion dollars.” One agent on that job produced zero dollars. Skip it if you have no distribution and no reason for anyone to care: the team was blunt that people likely would not have played their game without the live audience. Skip it if you will not stay on vision, taste, and merge judgment. Bots did not replace that.

Align on an idea, then ship an MVP

The goal of the first movement is not a complete business. It is a core loop in front of real users.

This group started by trying to serve a real person in an in-real-life business. After guest interviews, they judged that too hard, pivoted to a game studio, and even then they did not keep the first design. They began with a marketplace for bot templates, an auto-battler concept, cosmetics, stadium ads, replay mechanics, complicated stat blocks, extra battlefields, and a rock-paper-scissors idea. What they actually launched was a thinner auto-battle game with a couple of ad slots left in.

Prepare three things before you build: an idea the team is excited about, a ruthless cut list, and a way for someone outside the room to try the product. Then:

Stop debating once you have alignment. Speed showed up after they picked something and shipped.
Write down every feature idea, then keep only what the core loop needs. They dropped cosmetics, extra battlefields, heavy stat blocks, and the rock-paper-scissors mechanic.
Leave one or two monetization hooks if they are simple — here, a billboard/ticker slot and a leaderboard bid — and throw the rest out.
Get a playable version out. Polish, ads, and factories came after there was a game.

Good looks like a product a stranger can use without a guided tour, plus a short list of things you refused to build. Failure looks like a whiteboard full of systems and no loop. The speaker who pushed restraint put it simply: with AI you can build anything, so you can also ship a million features that are not any good.

The hardest part is usually getting people to care or building something that people care about.

Distribution is not a bot problem. This team had a crowd watching them work. Treat demand as a separate, human-hard constraint.

How to assemble a Grok Bot team

The goal is a staff, not a single assistant. Think in roles you would hire, including roles that cover what you personally do not know.

Prepare a short org chart and a place the bots can work in public (Slack, the repo, a canvas, the live product). The roles this team actually ran:

Chief of staff (they called one of them Steve): watch the work happening, pull clips and posts, produce a recap.
Data bot: pull live metrics on demand.
Feedback factory bot: watch the feedback channel, dedupe, open fix work.
Cursor cloud agents: take those issues, reproduce, patch, test.
Dr. Egg Bot: a bot for creating other bots, including naming and spawning specialists.
Game-design bots: learn from the best games, then advise on the product.
Playtest / “cheater” bot: try to win (theirs made the score go down — still useful as a signal).
Learning bots: when you enter a discipline you do not know, send them to take courses and gather advice.

What good looks like: you can open the bot’s browser or thread and see it working without a status meeting. What failure looks like: one generic bot asked to “run the company,” or a specialist with no context. A guest pattern they adopted was to flood a new-discipline bot with coursework instead of assuming it already knows permitting, catering, kitchens, or whatever the domain actually requires.

Don’t be afraid to assemble a really varied team of bots and think of them the way you’d think of hiring a group of employees.

Matt’s rule sits on top of the org chart: if you are going to build a business with Grok Bot, build it around something you already do well. Bots can cover gaps. They are a poor substitute for never having done the job.

Build a feedback-to-fix software factory

This was the defining system of their last day: user feedback in, merged fixes out, with as little human ticket-wrangling as possible.

What to prepare

You need a single feedback inbox, a repo the agents can touch, a way to reproduce bugs, and an explicit merge policy. They used Slack channels for marketing, socials, metrics, bug reports, and ad bids. Feedback arrived as bug reports and “bad design” notes, including from in-product phone and text feedback. Lauren’s factory supplied repro skills and a goal so agents were not guessing.

The loop

Stand up a dedicated feedback Slack channel. Do not mix it with random chat.
Point a Grok Bot at that channel. Its job is to watch, not to chat.
Dedupe. Incoming notes like “past matches look static” and “match history UI appears stale” should collapse into one piece of work.
Attach repro steps, related in-flight work, and a clear goal.
Kick off Cursor cloud agents to fix the issue.
When tests confirm the fix, land it. Their autopilot was described as YOLO, and separately as /potato mode full autopilot.
Close duplicate human PRs that are doing the same job so the factory does not fight you.

Good looks like a stream of small, related fixes with repro, tests, and a merge — not a graveyard of duplicate tickets. They were landing many PRs this way (one stretch mentioned 13). Failure looks like production going down: a bad SQL query from the factory took prod offline while they were talking about signups. Autopilot is only “good” if someone is watching uptime.

Give the factory write access on purpose. In their setup, one person still had to ask for GitHub collaborator permissions while others could merge. Decide that before you turn YOLO on.

Bot use cases by function

Use case	Bot / tool	Input needed	Output	Owner
Product feedback → fix	Grok Bot + Cursor cloud agents	Slack/app feedback, repro, in-flight work	Deduped issues, tests, merged PRs	Engineering
Live recap	Chief of staff bot (Steve) + tldraw	Stream, clips, X posts	Recap poster / three-day plan visuals	Comms / ops
Metrics snapshot	Data bot	Product analytics access	Games, signups, page views, charts	Founder / ops
Game design	Game-designer bots	Examples from strong games, product context	Design advice and iteration	Product
Spawn specialists	Dr. Egg Bot	Role, theme, what the new bot should do	New bots on the team	Founder
Playtest / exploit the rules	Cheater bot + rules page	Game access, rules.md	Score movement, broken strategies	Product / QA
Growth experiments	Playbook work with revenue ops (Matt)	X follows, partner lists	DM new followers; pitch game hosts/distributors	Growth
Monetization	Ad bid flow (still fragile)	Advertiser name, SVG logo, URL, bid	Ticker or leaderboard placement	Growth / eng

Teach bots with context and agent-friendly docs

The goal is not a smarter one-shot prompt. It is a bot that can keep learning the job.

Prepare source material the way you would onboard a new hire: rules, examples, and a page a model can fetch without a human sitting in the UI. They eventually published thursdayarena.com/rules so a bot could read how to play. The page rendered rules.md and included llms.txt. They called the result agent-friendly, and they also reported ranking first on Google for Thursday Arena / Thursday Space Arena with positioning around a free browser auto battler (they attributed that SEO pass to Cursor).

Do this in order:

Write the actual rules of the product in a durable file, not only in a human tutorial that arrives on day three at 4 p.m.
Make that file fetchable by agents (markdown plus llms.txt, with auth considered).
When a bot is new to a discipline, tell it to take courses and study the best existing work — their game-design bots learned from the best games.
Point playtest bots at the rules instead of hoping they infer the scoring system. They added a rules endpoint specifically so a bot could be told to read it and learn how to win.
Let bots inspect their own browser session so you can see whether they are actually working.

Good looks like an agent that can open rules, cite in-flight work, and act without a huddle. Weak looks like a recap bot drawing boxes that are “not that great,” or a playtest bot that lowers your score because it never read the rules. Context is the fix they said they had undervalued.

You can give the bot lots of context. You can teach them all the things they need to know.

Glue the stack, then add one monetization path

Do not rebuild the company substrate. This team stood on existing engineering products and treated Grok Bot as the glue: PlanetScale for the database, Clerk for authentication, Vercel for deployments, Stripe for payments, Slack for internal routing, GitHub for the factory, X for distribution experiments.

On go-to-market, they used a normal business playbook, just compressed into fewer people. Revenue operations ideas they actually discussed:

When someone follows you on X, send a DM and tell them to try the product.
Talk to companies that host or distribute games and try to get featured on those lists.
At zero-to-one, sales, partnerships, and revenue operations may be one role, not three.

On monetization, they kept ads after cutting cosmetics. The intended surfaces were a ticker/billboard and buying your way toward the top of the leaderboard. A live test needed an advertiser name, an SVG logo, a URL, and a bid (they placed a $1 bid). The auction was broken, sponsored bids did not reliably take the top spot, logo upload failed until they used an SVG, there was no reload on failure, and moderation of user-submitted creative was broken. They still treated a theoretical first sponsorship dollar as a useful end state: the path existed, the plumbing did not.

Good looks like one chargeable action that can complete. Failure looks like bidding UI that accepts money-shaped input while placement, moderation, and auctions disagree with each other.

Prompts, bot instructions, and workflows

The source did not include full system prompts. These are cleaned, copy-ready reconstructions of what they told specific bots to do.

Chief of staff recap bot (reconstructed from the speaker’s description):

As we wrap up the day, watch the live stream. Look for clips and tweets, especially the interesting ones. Draw a recap poster in tldraw.

Research-and-illustrate recap (reconstructed from the speaker’s description):

Look us up on X. Figure out the details of what we did over the last three days. Draw pictures in tldraw. I am not going to feed you the numbers — go get them.

Feedback factory bot (reconstructed from the speaker’s description):

Watch the feedback Slack channel.
Dedupe incoming feedback (bugs and bad-design notes).
For each unique item, attach repro steps, related in-flight work, and the goal.
Kick off Cursor cloud agents to fix it.
When tests confirm the fix, merge. YOLO / full autopilot is on.

Playtest bot, once rules exist (reconstructed from the speaker’s description):

Read https://thursdayarena.com/rules and learn how to win.

New-discipline research bot (reconstructed from the speaker’s description of a guest workflow):

We are entering a discipline we have not done before.
Go take a bunch of courses on the internet on this topic.
Come back with advice covering the operational details we would otherwise miss.

Merge policy they used in the factory (as spoken):

/potato mode full autopilot

Optional culture note, not a required workflow: Dr. Egg Bot was told to use food-theme, specifically potato-theme, names. A task snuck into Notion that every merged pull request should be called a mash. The chief bot then only believed in mashing PRs. Funny, and a warning that instructions leak into production language.

What they measured after three days

There is no universal dashboard in this method. The checkpoint they used was: did a real product exist, did strangers use it, and did the factory keep moving while they talked.

Late on day three, the data bot was asked for a snapshot. The team reported crossing 4,000 games after already crossing 6,000 public matches, a 4:00 p.m. bump in X signups, a hope of crossing 2,000 cumulative users before wrap (prod going down made that uncertain), close to 30,000 page views, number-one Google ranking for their name, and inbound traffic from several sites. A recap bot independently surfaced 4.5k games without being handed the number. They also tracked diamond-player counts and win-loss bugs as quality signals, and they treated “first theoretical sponsorship dollar” as a monetization checkpoint even when the auction was wrong.

Use those as examples of qualitative gates — usage, distribution, ranking, whether money can move, whether prod stays up — not as a forecast for your launch. This run had a live audience. They said that was the easy way to get people to try the product.

Pitfalls and guardrails

Do not start with a domain you have never practiced. A guest rattling off event-popup constraints (permitting, catering, hot food vs. cold food, whether you need a kitchen) was the example. Professionals know those lists because they have done the work. Bots help more after that.

Do not confuse build speed with product quality. They came in with a crowded whiteboard and got something launched by paring down to the core loop. Internally they ask “what are we going to unship?” Keep that question on the factory, or it will add features as fast as it fixes bugs.

Do not skip the human discovery step. Organic problem-finding still belongs to people. Encoding the fix into a bot comes second. That is how the factory grows over time without hallucinating a department you never needed.

Autopilot can break production. YOLO merging, a bad SQL query, and a factory that “just merging and disappearing” is working until the site is down. Keep a human on uptime, especially if agents have write access.

Customer-facing money and media need extra brakes. Ad auctions, leaderboard bids, SVG uploads, and moderation of user-submitted logos were all fragile. Theoretical dollars are not the same as a safe sponsorship pipeline.

Playtest bots can optimize the wrong thing. The cheater bot moved a score from the high 980s into the 950s. Point those bots at rules, then discipline the strategy.

Instructions leak. A potato-themed naming bot rewrote merge vocabulary across the team. Harmless here. Less harmless if a bot invents policy in Notion or in customer copy.

Humans still own taste and drive. One speaker’s split: every team needs someone with a clear vision and judgment about what goes into the product, and someone relentless at making things happen — better if one person can do both. That remains a human role as models get more capable.

If you’re going to build a business with Grok Bot, build a business around something you already know how to do well.

7-day implementation plan

This follows their three-day arc, stretched into a week you can actually staff. It is not a generic agile sprint.

Day 1 — Pick the business you already know

Write the domain you can already operate without a bot. Align the humans on one idea that gets a real reaction. List every feature you are tempted to build, then circle only the core loop. If you cannot explain the loop in a few sentences, you are still deliberating. Do not staff a dozen bots yet.

Days 2–3 — Ship the thin MVP on glued infrastructure

Stand up auth, database, deploy, and payments with tools you do not have to invent. Create Slack channels for feedback, bugs, metrics, marketing/socials, and any money path (their ad-bids channel existed before bids actually flowed). Ship something a stranger can use. Cut cosmetics-level ideas without mercy. Publish a rules or how-it-works page in markdown while you still remember how the product works.

Days 4–5 — Turn pain into a factory and a bot roster

Use the product yourself and collect messy feedback. Only then build the watcher bot: dedupe the channel, attach repro and in-flight work, hand off to coding agents. Add llms.txt and make the rules agent-friendly. Spawn specialists for the gaps you felt — design, data, recap, playtest — and send learning bots at any discipline you still do not know. Decide merge policy in writing (human approve vs. YOLO) before the factory is loud.

Days 6–7 — One growth play, one money play, then unship

Run one distribution action from their playbook (for example, DM new followers with a reason to try the product, or talk to a distributor). Run one monetization path through to completion, including moderation. Pull a metrics snapshot. Kill anything the factory added that is not the core loop. Name the two human jobs for the next week: who owns taste, who owns making it happen.

Start with one workflow, not a fake company

The point of this method is not a game studio and not a three-day stunt. It is a way to put a team of Grok Bots next to work you already understand, so shipping, feedback, and maintenance stop living entirely on your calendar. Pick one loop you felt this week, document it, and give it a single owner bot. Watch the video for the factory walkthrough if you need to see the Slack-to-merge path in motion — then start with that one bot, not a full org chart.

FAQ

Can I build a company with Grok Bot if I have never done the job?

The team’s direct advice was no: build around something you already know how to do well. Guests who had actually run events could list ten operational constraints the builders had never considered. You can add bots that take courses and gather advice for the gaps, but that is cover, not a substitute for practice.

Do I need a live stream or a big audience first?

You need some reason for people to care. This group said getting people to care was the hardest part, and they did not think anyone would have played the game without the stream. Bots helped them ship and repair. They did not create demand from zero.

Grok Bots vs hiring people — what still needs a human?

Use bots for work you have already figured out and want running forever: deduping feedback, drafting recaps, pulling metrics, learning a specialty, opening fix PRs. Keep humans on vision, product taste, judgment about what to unship, and relentless execution. One speaker called that pairing a distinctly human role even as models get more capable.

Do I need Cursor if I already have Grok Bot?

In this workflow, yes for the software factory they ran. Grok Bot watched Slack, deduped, and kicked off Cursor cloud agents to reproduce, patch, test, and merge. They also used Cursor for an SEO pass. If you are not shipping code, you may not need that handoff — but then you also do not have their factory.

Should I let bots YOLO-merge pull requests?

Only if you accept production risk. Autopilot is how they landed a high volume of fixes, including win-loss bugs, and how a bad SQL query took prod down. Set write access deliberately, watch uptime, and keep a way to revert. YOLO is a merge policy, not a quality strategy.

What should I do in the first 24 hours?

Pick a domain you already know, cut to a core loop, and create one feedback channel. Do not start by spawning a full executive team of bots. The acceleration in their run came after alignment and an MVP, not after more ideation.

How do I keep the product from turning into feature sludge?

Ask what you will unship, on purpose. They had extra battlefields, heavy stat blocks, cosmetics, and extra mechanics on the whiteboard. Launching required paring to the auto-battle loop and a couple of ad slots. When agents can build anything, restraint is part of the method.

Can I just prompt a bot to make the money?

They tried the joke version. An agent ran from the start of the stream and still had zero dollars. Money in their run looked like ordinary work: a growth playbook, partnership ideas, and a still-broken ad bid that needed logos, moderation, and an auction. Prompting “make a billion dollars” was explicitly treated as a mistake.