Solo developers

You don't need a miniature company process to run a solo product. A good setup gives you one place to decide what ships next, enough structure to find work quickly, and a coding agent that can act without asking for context every session. The example below is a subscription analytics product heading toward an MVP.

Recommended setup at a glance

Part	Example setup
Project	Metrics app
Product context	Subscription analytics for solo SaaS founders who need a clear view of revenue and churn
Areas	Dashboard, Data import, Billing
Active release	MVP
Starter tasks	Connect Stripe, calculate MRR, build the overview dashboard, invite five testers
Cadence	You own every task; review the release for five minutes each week
Agent role	Turn the release outcome into tasks, pick up the next one, stay tied to the product context

One project, a clear product context

Create one project for the product. Don't split frontend, backend, and marketing into separate projects; they're parts of the same outcome and belong in one plan.

Then write the product context: what the product does, who it serves, and the problem it fixes. Keep each answer short enough to use when making a tradeoff. For the example above: "Subscription analytics for solo SaaS founders who need revenue and churn answers without maintaining a data stack."

Your coding agent reads this context too. A precise paragraph gives it a better basis for proposing tasks than a backlog of disconnected ideas. See Product for the fields Frostbyte stores.

Keep one active outcome

Name the active release after a result you can demonstrate, not a date or a bucket like "v1 work". MVP works because it has a finish line: a small group can connect billing data and understand the dashboard. Tasks that don't move you toward that stay out of the release.

Start with three to five tasks. If the release needs fifteen unrelated ones, the outcome is too broad; split it before you start building. When it ships, write the notes, mark it complete, and pick the next outcome. Completed releases stay as history, so you don't need a separate changelog spreadsheet.

Add areas when they remove friction

Areas are stable parts of the product, not phases of work. A new project can start with a flat task list. Add areas once the same systems keep appearing, or when finding related tasks starts taking effort.

For the metrics example, Dashboard, Data import, and Billing are enough. Skip areas for beta, launch, bugs, or design; those describe a release, a task type, or a discipline. Free supports five areas, which is a useful constraint for a focused solo product.

Use the agent for planning admin, not judgment

Ask the Frostbyte agent to draft an area set or turn a release outcome into a short task list. Connect Claude Code or Codex when you want an agent to read the live plan, work on a task, and report back. The plugin guide covers installation and repository linking.

Keep the founder decisions for yourself: which user matters, which problem is worth solving, and what must ship now. Delegate the mechanical work of structuring and updating the plan.

Add feedback once someone can use the product

Don't build an intake process before you have users. When testers arrive, enable the Feedback Portal, in full or bugs-only mode. Reports land in one queue, you review them against the active release, and only the actionable ones become tasks. A report can be valid and still wait.

Run it in five minutes a week

1. Read the active release outcome and check it's still the next thing worth shipping.
2. Remove, split, or defer any task that no longer helps that outcome.
3. Pick the next unblocked task and make its expected result clear.
4. Review new feedback, but don't expand the release by default.

You're not trying to keep Frostbyte tidy. You're trying to leave each review knowing what to build next and why.