Skip to content
StellarFirmStellarFirm
Join waitlist
Mission manual
Esc

Type a word to search every page. Try , or .

Module 04 · Company playbooks

Solo founder

A plan for one person building a product alone: set up the Coder, write light house rules, and ship small fixes fast while you keep the big decisions.

View as Markdown
On this page

You are one person with a product, a backlog, and not enough hours. This playbook puts the Coder to work on the code while you stay in charge of what ships.

Who this is for#

CompanyOne founder, one product
Team size1
Main goalGet more shipped without hiring yet
Start withThe Coder on your main repository
Biggest riskTrusting it too fast, or never trusting it at all

Your assistants#

AssistantStatusRole in this plan
CoderAvailableBuilds features, fixes bugs, keeps checks green, writes tests
Product ownerComing soonKeeps your backlog clear and ranks the week
MarketingComing soonLaunch posts and changelogs
AccountantComing soonInvoices and monthly expense summaries
LegalComing soonPrivacy notice and terms checklists

Suggested house rules#

As a solo founder you are also the reviewer, so you can let the Coder go further than a larger team would. Paste something like this into your company brief and edit it to fit.

Text
House rules
1. The Coder works on its own branch, never directly on [main branch].
2. For small fixes (a typo, a copy change, a dependency bump, a bug fix under [number] lines), the Coder may merge once all checks pass, and tells me afterwards.
3. For anything bigger, or anything that touches [payments, sign-in, or customer data], the Coder opens a pull request for me to review and waits.
4. Production deploys always wait for my Approve.
5. The Coder adds a test for every bug it fixes.

Preflight#

Finish these before Day 1.

  • Sign in at https://stellarfirm.ai/app with the invitation you received. Self-service sign-up is not open yet.
  • Connect your source host (GitHub, GitLab, or Bitbucket) on Integrations.
  • Pick one repository to start with.
  • Check that the repository has checks (tests or lint). If it has none, your first goal will be to add them.
  • Write your house rules in the company brief.

Launch: Day 1#

  1. Say hello to the Coder. Ask it to look around so you both start from the same picture.
PromptGet a first look at the repository
Coder, look at [repository]. Tell me what it does, how to run its tests, and the three things you would fix first.
  1. Run the first goal. Choose a small, real change.
PromptYour first goal
Coder, pick up the smallest open issue on [repository]. Build it, run the checks, and show me the changes. Follow our house rules for what happens next.
  1. Watch it work. Open Jobs to see the commands and the changes, and Computer to see its workspace.
  2. Approve the risky step. When the Coder asks to push and open a pull request, read the changes, then Approve in Approvals.
  3. Read the result. By default you get a pull request, as a draft. If it was a small fix and your house rules allow merging, it can ship and tell you.

First week#

DayDo this
2Give the Coder a bug from your list, with a regression test.
3Ask it to fix any failing check and to review one of your own pull requests.
4Ask for tests on the part of the code you are most afraid to touch.
5Review how it went. Loosen or tighten your house rules.
PromptFix a real bug
Coder, on [repository], fix this bug: [description and steps to reproduce]. Find the cause first, add a test that fails without the fix, and then fix it. Follow our house rules for what happens next.
PromptGet your own pull request reviewed
Coder, review pull request #[number] on [repository] as if you were a careful teammate. Point out risks, missing tests, and anything confusing.
PromptGet a safety net of tests
Coder, write tests for [module] on [repository]. Cover the edge cases and do not change the behavior. Open a pull request for review.
PromptCheck a page in the browser
Coder, open [page] from [repository] in the browser, click through the main flow, and report anything broken with screenshots.

Steady orbit#

A rhythm that fits around your other work:

  • Monday. Choose the week's goal. Ask the Coder to take the top ticket.
  • Midweek. Read the pull requests waiting for you in Approvals.
  • Friday. Ask the Coder what shipped and what is stuck.
  • Monthly. Revisit your house rules. If small fixes keep landing cleanly, widen what the Coder may merge.
PromptWeekly check-in
Coder, summarize what you shipped on [repository] this week, what is waiting for me, and what is blocked. Suggest the top three things for next week.
PromptClean up after a release
Coder, look at [repository] after our last release. List any follow-up fixes, flaky tests, or leftover tasks, and open issues for the ones that matter.

Coming soon for your company#

When the other personas open, a solo founder gets the most from these:

  • Product owner: ranks the week so you always start on the right ticket.
  • Marketing: turns each release into a changelog and a launch post.
  • Accountant: summarizes the month's expenses and drafts invoices.
  • Legal: drafts a privacy notice checklist for your sign-up form, for your lawyer to review.

Pitfalls#

  • Opening the door too wide, too soon. Start with pull requests for review. Allow merging for small, low-risk changes only after you have read a handful of diffs.
  • Goals that are too big. "Rebuild the app" produces a diff you cannot review. Ask for one change at a time.
  • Skipping the checks. Auto-merging only makes sense when your repository has tests. Add them first.
  • Forgetting to name the repository. Always say which one, especially if you have several.
  • Never reading the diff. Open the job in Jobs before you approve anything risky.