Hire Grokbot Employees to Prototype and Ship With Cursor

Key takeaways

• Hire Grokbot employees with funny names and a single job before you write a long spec. Give each bot its own context instead of dumping everything on one thread.
• Start with a market research bot connected to X. Synthesize replies you already have rather than inventing the product in a room.
• Use a simple customer / pain / value lens. Bias toward something physical, local, or service-heavy. The speakers treated “not another SaaS demo” as a real filter, not a joke.
• Talk to bots the way you talk to teammates: interrupt them, heart the messages you like, ask for a status every few minutes, and dictate a messy brief, then make the bot restate it.
• Use Dr. Eggbot (marketplace) to spawn and rewrite other bots. Keep a lightweight prototyper for throwaway HTML, and send serious engineering to Cursor cloud agents.
• Write one short company doc and feed that same context to every bot and every guest. Verbose docs go stale and poison outputs.
• The first loop is not a stack of landing pages. Find location, operators, and food people first. Attendees and software come after.
• Make bots proactive. Ask for numbered check-ins you can answer one by one. A human still picks the idea, talks to real operators, and decides what ships.

Who this is for (and who should skip it)

This is for a founder, product manager, marketer, or ops lead who will actually sit in Grokbot, connect a few plugins, and run a messy first week. Peter Yang uses Grokbot to run a one-person business (newsletter Behind the Craft and a YouTube channel) and talks to bots all day. The live team assumed Grokbot, an X account, Slack, Notion, GitHub, and later Cursor, Vercel, and PlanetScale. You do not need to be a heavy AI coder. One stated bar was a business a non-technical parent could understand.

Skip it if you want a finished playbook with conversion numbers, a priced stack, or a guaranteed idea. The session is a company-formation method, not a completed product. Skip it if you refuse to talk to real customers. The speakers were explicit: chat viewers are not automatically your buyers, and people will compliment an idea without paying.

Stand up the company shell, then hire the first bot

You are not trying to look like a company. You are trying to give humans and bots a place to work. The team stood up a blank GitHub org (Ship by Thursday), a Slack channel so people and bots could chat, and a Notion workspace for a handbook and backlog. One view was to stay scrappy and skip docs because they go out of date. The other was to write things down so bots inherit the same story. Both happened. The useful rule is: create the channels, then hire, then write only the context bots need.

Open a blank Grokbot. Connect the X plugin (spoken as X MCP) and authenticate the account you will research from. Plugins are how work gets done: you attach the systems the bot must touch instead of pasting screenshots forever. Featured bots live in the marketplace; install those as you need them rather than building every employee from zero.

Name the bot like a coworker

Peter’s first best practice: give it a really funny name. A generic “market research bot” is a function. Marky McMark Face is an employee you can talk to. That sounds cute. It is also how you remember who owns which context when you have five bots in the sidebar.

What good looks like

Good setup is boring: org exists, Slack exists, Notion exists, Grokbot is authenticated to X, and one named research bot is ready. Failure at this stage is waiting for the idea before you hire, or hiring a bot with no plugin so it cannot see the customer messages you already collected.

Turn existing replies into a product bet

The hard part of starting is talking to users. The team already had a pile of signal: an X prompt asking what to build, the same question in Slack, and thousands of messages plus live-chat ideas. The first job for the market research bot was not “invent a startup.” It was: synthesize feedback from people replying to recent posts.

If the bot goes quiet, nudge it. One trick: tell it to give you a status update every three minutes. Another: interrupt and redirect. Heart a message you like. Grokbot notices the heart and folds that preference into the follow-up. That is a faster research loop than waiting on a single long report.

Filter ideas with a customer, pain, and value lens

Peter’s product-manager frame: who is the customer, what is the pain, what is the value. The team added constraints from the room and the replies:

• Not another SaaS demo. People asked for something physical, local, or for non-tech customers.
• Accessible enough that a non-technical person could understand it. Lauren’s example was her mom, who barely uses email.
• Cool enough to show interesting tech, but still a real business that helps people, not an esoteric demo.
• No meme coins or crypto. Those got cut on the spot.
• Platforms that help other people operate (small businesses, restaurants, creators) beat a pure toy.

Themes that survived that filter included hardware and local services, consumer-fun ideas, a company that helps people build companies, book marketing, landscaping, and restaurant operations. The team locked on a restaurant pop-up direction: an OS for spinning up pop-ups, plus dogfooding by running a real San Francisco food pop-up. Working names floated around pop-up OS, kitchen desk, and later a company wrapper called Ship by Thursday. Potato Lab showed up as a meme-y alternative. None of that is a proven market. It is the bet they chose so bots had a job.

What good looks like

Good research output is a short list of themes, a rejected pile (SaaS clones, crypto), and one direction crisp enough to write user stories. The research bot also suggested day-one demos: a morning brief for a restaurant ops manager, review management for an owner, contractor help for household chores, volunteer coordination. Use those as spikes, not as a roadmap you owe.

Failure: treating livestream chat as the customer, or building two landing pages before you have a location, a cook, and a reason someone would show up. Steve (a renamed default bot, later chief of staff) called that out: the bottleneck is the first loop, not a mega page.

Split the work across specialist Grokbot employees

Once the bet exists, stop using one brain. Dr. Eggbot is Lauren’s marketplace bot, built on her P-stack plugins, and taught to create high-quality bots. It can inspect your other bots and rewrite them. That is how you go from a lonely sidebar to a small team without hand-authoring every system prompt.

The live split looked like this:

Use case	Bot / tool	Input needed	Output	Owner
Market research	Marky McMark Face plus X plugin	Replies to recent X posts and Slack ideas	Themes, rejects, user-story sparks	PM / founder
Orchestration	Steve as chief of staff	Voice dumps, company doc, routing requests	Restated plans, assignments to other bots	Founder
Throwaway UI	Food-themed prototyper (Crockpot / later Grokbot as prototyper)	Direction, references, design feedback	Inline HTML/CSS/JS pages rendered in Grokbot	PM / design
Prospecting	Prospecting bot via Dr. Eggbot	Pop-up brief, city, chef vs. guest split	Feasibility, restaurant sources, outreach options	GTM / ops
Prioritization	Prioritization bot	Stream-of-consciousness overwhelm	Ideal restaurateur brief, spike list, lead map	Founder
Engineering	Tater plus Cursor cloud agents	Repo, stack preferences, “no endless debate”	Code, deploys, later reviews	CTO
Ops and brand	Ops bot, creative director, marketing bot, design bot	Company one-pager, naming constraints	Domains, titles, playbook, visual direction	CEO / CPO

Talk mostly to the chief of staff. Let specialists own their context. Ask Dr. Eggbot to change names, rewrite roles, or have one bot message another. Everything is chat-first: if you hate a name, say so and it changes. If you want a prototyper that only emits loose vanilla HTML, say that and give it a food-themed name. Chat voted pickle, nacho, waffle, dumpling, churro, meatball, Crockpot, Spud, Tater, gnocchi. They used Crockpot for the prototyper and Tater for the engineer. The point is not the potato jokes. The point is one bot for throwaway mocks and a different bot for the stack.

Prospect before you build the marketplace

A pop-up platform still needs a restaurateur who can cook, guests who want the food, and the logistics in between. That means outreach to real humans. The prospecting bot’s first job was restaurants and restaurateurs, not attendees. Sources they named: X, people watching who know an SF owner, a submit form, a phone number, or email. They did not have company email yet. That is a real blocker. Bots cannot skip “do we have an inbox?”

Peter’s solopreneur filter belongs here: design a business around work you actually enjoy. You can choose the higher-revenue path and hate the days. For idea quality, get market signal fast. Internal debate and giant documents are how PMs used to ship things nobody wanted. Try to see if someone will pay. Do not get too attached. Ideas are cheap; the team is what matters. He also argued it is hard to make money from pure software now because anyone can ship a landing page with a database. People pay for the hard part: finding a restaurateur, cooking, putting on the event.

Prototype in Grokbot, then hand engineering to Cursor

Do not file a ticket you could prompt. Lauren’s Slack status is permanently “why not today?” The input box is treated like a spell: instead of a detailed PRD, get a clickable prototype into the argument. Working with bots felt closer to a strategy game than to writing briefs engineers would not read anyway.

Practical sequence they used:

1. Dictate for about two minutes. Yap. Then tell the bot to ignore the noise and do the job anyway. Edit the transcript if the dictation is garbage.
2. Before pixels, ask for high-quality landing page references and assemble a tiny mood board. Pick a direction. Food you sell changes the design. “French fries” is a different page than “platform for restaurateurs.”
3. Decide how many faces you need. A platform page for operators is not the same as an event page for people buying food. Steve’s useful pushback: you may not need all of those pages yet.
4. Render HTML and CSS inside Grokbot. You do not have to deploy to see it. Give blunt feedback (“too boring, too bland”) and heart the direction you want (they picked night-market pink).
5. Create a repo when code needs a home. They opened a public-or-private pop-up repo, then connected Vercel and pushed an extremely scrappy index.html with inline styles. Live on the internet beats a prettier mock that never ships.
6. Collect signups somewhere dumb first: Google Sheet, Notion database, or a flat file. They debated Notion load, then asked Steve to wire the page to a Notion database. They also considered going straight to PlanetScale Postgres so they would not rip out a toy database later. Payments were explicitly later.
7. When fidelity has to rise, stop asking Grokbot’s lightweight harness to be a coding agent. Grok is the model; Grokbot is a thin harness. Cursor’s harness is what they wanted for real engineering. Tell the engineer bot to spawn Cursor cloud agents, optionally a long-running project agent that keeps technical context, and to come back with a screenshot or video. Cloud agents can run the app, click around, and test. Grokbot can still orchestrate them.

Stack preference in the room: Vercel to host, PlanetScale Postgres when they were ready, friends from those teams incoming, and “let the bots pick the rest.” Avoid endless tech-stack debate while you are still hunting product-market fit. New working rule once a bot opened a 2,000-line pull request: no PRs, ship to main until someone yells. That is a speed rule for a three-day build, not a universal engineering standard.

They bought shipbythurs.day as the company domain and treated it as the org lander. The product would get a different name and domain later. Working titles from a naming bot included claimstall.com, stall.run, nightmarket.app, pop-up.place, openstall.co, peanutpop-up.com, and hostapopup.com. Nobody loved them. That is fine. Ship the HTML.

What good looks like

Good is a prototype you can look at, a deploy on main, a place to drop emails, and an engineer bot that knows to use cloud agents. Failure is debating seated tasting menus versus a french-fry counter while nothing is live, or asking the lightweight prototyper to be your production codebase.

Prompts, bot instructions, and workflows

These are cleaned from spoken instructions. Where the speaker described the job instead of pasting a prompt, the block is labeled as reconstructed.

Market research, as spoken:

Synthesize feedback from what's been suggested by people replying to our recent posts.

Keep the bot from going dark:

Give me a status update every 3 minutes.

Confirm the bot heard a voice dump:

Restate to me what I just said in your own words so I know you understood me.

Reconstructed from the speaker’s description of the prospecting bot:

I need a prospecting bot. Help me evaluate the feasibility of research for a restaurant pop-up business. Find restaurants and restaurateurs first, then people who might attend. Consider sourcing from X, from people who know an owner in San Francisco, and from a landing page, phone number, or email where people can reach us. Help me evaluate those options and eventually build the systems behind them.

Reconstructed from the speaker’s description of the prototyper:

Make a prototyper bot that makes loose HTML, CSS, and JS vanilla prototypes. Give it a fun food-themed name.

Turn a default bot into an orchestrator, as spoken:

Turn Steve into my chief of staff / executive assistant.

Landing-page research, as spoken:

What are some high quality sources of good landing page design? Find some references.

Reconstructed from the pop-up platform voice dump after they asked Steve to ignore the noise:

We're building a pop-up platform startup. Work with Dr. Eggbot to engineer a small team and put together a loose, scrappy prototype so we can validate the idea. We may not need a database to start; a Google Sheet is fine. Put together a landing page for the pop-up idea and disregard the noise we contributed.

Speed rule for the repo, as spoken:

New rule: no pull requests. We ship to main for now until somebody yells at me.

Peter’s preferred check-in format: have bots send updates as a numbered list so you can reply “good idea” or “bad idea” line by line. He likes a Friday check-in from every bot.

Measurement and business impact

Nobody in the session gave time-saved figures, costs, lead counts, or conversion rates. The checkpoints they actually used were qualitative:

• Did the bot restate the plan in its own words, including the multi-face landing-page split and the first-loop bottleneck?
• Did hearted messages change the next suggestion?
• Do you have HTML you can see without a deploy, then a URL after Vercel?
• Is there a place to store signups?
• Are specialist bots pushing numbered updates you can answer, instead of waiting for you to poke them?

Peter’s business test is still the one that matters: will a customer pay, and are you building the hard physical or service layer people cannot spin up themselves?

Pitfalls and guardrails

• Wrong customer in the room. Livestream chat will brainstorm NeoPets, Club Penguin, and crypto. Use it for energy, not as the buyer. Put the landing page in front of restaurateurs if restaurateurs are the customer.
• Compliments are not revenue. People will say an idea is good to be nice. Try to get the first dollar.
• Pure software is easy to ignore. A landing page plus a database is no longer scarce. If there is no ops, service, or physical component, the speakers expected pricing power to collapse.
• Too many pages, not enough loop. Operators, kitchen, location, then guests. Software for booking tables is optional if you run a counter line.
• Context bloat. Feed bots a concise description of what you are doing. Bad information in means bad output out. A stale Notion wiki is worse than a one-pager.
• One mega-bot. Split specialists so each owns context. Use a chief of staff so you are not the router for every task.
• Wrong harness. Lightweight in-Grokbot HTML is for looking and feeling. Cursor cloud agents are for building. Mixing those up produces either slow mocks or sloppy production code.
• Over-ambition. Platform plus dogfooded pop-up in three days is a stretch. Pivot is allowed. Human still chooses seated experience versus fries-at-the-counter.
• Clerical work does not vanish. Slack, screen share, GitHub permissions, Vercel invites, PlanetScale credentials, company email, and a domain still require a person. Automate after the account exists.
• Lonely bots. Peter’s feature request: let humans jump into the same interface as the bots. Until that exists, you still need Slack (or equivalent) so people are not only talking to employees who never talk to each other.

7-day implementation plan

The live team was trying to ship by Thursday. Stretch the same sequence across a week. Do not add work they did not do.

Day 1. Create GitHub, Slack, and Notion. Open Grokbot, connect X, hire a named market research bot. Paste the synthesize-replies prompt. Ask for a status every three minutes. Dump existing posts and Slack ideas into it. Write five sentences on who the customer is not (another SaaS buyer, a crypto trader).

Days 2–3. Run themes through customer / pain / value. Kill ideas that are pure software with no service layer. Lock one direction even if the name is temporary. Install Dr. Eggbot. Rename your default bot as chief of staff. Hire a prototyper and a prospecting bot. Dictate the plan once and force a restatement. Put that restatement into a one-page company doc and share it with every bot.

Days 4–5. Ask for landing-page references, pick one visual direction, and generate HTML inside Grokbot. Heart what you like; reject bland corporate pages. Open a repo, connect Vercel, ship to main. Buy a domain when you have a company wrapper name. Store signups in Notion or a sheet. Start prospecting for real operators in one city. Do not wait for the perfect product name.

Days 6–7. Stand up an engineer bot and tell it to use Cursor cloud agents. Add a reviewer bot if PRs appear anyway. Wire a real database only if the signup path is already live. Set Friday numbered check-ins on research, prospecting, and engineering. Personally message or call one operator. Decide the first loop: counter versus tables, mystery pop-up versus named restaurant, platform page versus event page. Keep a human on naming, money, and anything customer-facing.

Get a bot team that pushes work, then go talk to a real operator

The outcome is not a clever bot zoo. It is a small set of Grokbot employees that research, prototype, prospect, and ship while you stay on the decisions that still require taste and a phone call. Hire one research bot, give it the replies you already have, and make it proactive before you add a designer, an engineer, and a creative director.

Start with one named bot, connect X, and document the first workflow in a page short enough to paste into every other employee.

FAQ

Do I need Cursor if I already use Grokbot?

For throwaway landing pages, no. Grokbot can emit HTML and CSS you can see in place. For serious engineering, the speakers treated Cursor’s harness as the thing that actually writes and tests code. The intended pattern is Grokbot orchestrates, then spawns Cursor cloud agents against a repo.

Should I start with a landing page or with real outreach?

A landing page is useful, and they deployed one. Steve’s correction still stands: the bottleneck is location, operators, and food people. Attendees come after. You can send emails and collect interest before the software is real. Do not build every public face first.

Grokbot employees vs a traditional PRD: which should I write?

The bias in the room was to prompt a prototype instead of filing a long spec. Product specs still have a place, but agents make a clickable thing a better argument than a document engineers may not read. If you write anything, write the short company context bots will reuse.

Do I need Dr. Eggbot?

You can create bots by hand the way Grokbot 101 showed. Dr. Eggbot is the shortcut they kept installing: it lives in the marketplace, uses P-stack, creates other bots, and can rewrite Steve into a chief of staff. Lauren treated it as a must-have. It is not required to run a single research bot.

Why not just build another SaaS with these bots?

Replies asked for physical, local, non-tech work. Peter’s view is that pure software is now too easy to copy, so a page with a database is hard to charge for. People will pay for the hard ops: a restaurateur, a meal, an event. That is a recommendation from the session, not a study.

How do I keep multiple bots from drifting?

Give each bot one job and its own context. Route through a chief of staff. Keep a concise company doc and paste it into new hires. Heart good messages, interrupt bad ones, and force a restatement after any long voice dump. Too much stale detail makes outputs worse.

Can a non-engineer run this Grokbot workflow?

Parts of it, yes. Connecting X, hiring a research bot, dictating a brief, and picking a prototype do not require a coding practice. The live build still needed someone comfortable with GitHub, Vercel, and Cursor to get past HTML. Match the bot you hire to the skill you have on day one.

Grokbot vs Slack: where should humans collaborate?

The team used both: Grokbot for bot employees, Slack so humans and bots could chat and share repos and invites. Peter’s complaint was that talking only to bots feels lonely. He wanted humans in the same channels as the bots. Until that exists, keep a human channel on purpose.