Solo Founder Startup OS

Problem

What painful problem are you solving, written in the customer's own words? Avoid describing your solution here.

Customer

Who specifically has this problem? Name a narrow segment, not "everyone who..."

Proposed outcome

What does success look like for this customer once the problem is solved?

Assumptions

List the riskiest assumptions this idea depends on — the ones that would kill it if wrong.

Risks

What could go wrong: market, technical, distribution, regulatory, or founder-fit risk?

Evidence

What have you already observed — search volume, competitor activity, direct conversations — that supports this problem being real and painful?

For each direct or adjacent competitor, fill in one row:

Look for a recurring gap across multiple rows — a weakness or unmet need several competitors share is a stronger signal than a one-off complaint about a single competitor.

Warm-up

• Tell me about the last time you dealt with [problem area].
• Walk me through what you did, step by step.

Problem exploration

• What was the most frustrating part of that?
• How often does this come up?
• What have you tried to fix it?

Current solutions

• What are you using today — a tool, a workaround, or nothing?
• What do you like and dislike about it?

Willingness to pay

• Have you ever paid to solve this, or looked into paying?
• What would make you switch from what you use today?

Wrap-up

• Who else deals with this the way you do?
• Can I follow up once I have something to show you?

Rule: do not describe your product idea until the interview is over.

Market mapping

"I'm exploring [problem/idea] for [target customer]. List the main categories of existing solutions (including manual workarounds and non-software options), the leading products in each category, and where the underserved gaps appear to be."

Interview synthesis

"Here are notes from N customer interviews about [problem]: [paste notes]. Identify the 3-5 most frequently repeated pains, group them by theme, and flag any pain mentioned by more than half the interviewees."

Objection discovery

"I'm proposing [one-line solution] to [target customer] for [problem]. List the most likely objections a skeptical version of this customer would raise, grouped by price, trust, switching cost, and timing."

Niche refinement

"Given this broad target customer: [description], and this evidence: [evidence], suggest 3 narrower sub-segments that would let me get to a stronger product-market fit faster, and explain the tradeoff of narrowing to each."

Problem

The top 1-3 problems worth solving, from your Stage 1 evidence.

Customer segments

Who has this problem? Include early adopters specifically — who would try this before it's proven?

Unique value proposition

A single, clear sentence: why is this different and worth switching to?

Solution

The smallest set of features that deliver the value proposition — not the full product vision.

Channels

How will you reach customers — the paths you actually have access to, not aspirational ones.

Revenue streams

How does this make money? Be specific about the model, not just "subscription."

Cost structure

What does it cost to build, run, and acquire a customer?

Key metrics

The 2-3 numbers that would tell you this is working.

Unfair advantage

What can't be easily copied or bought by a competitor — your specific edge.

Problem

Restate the validated problem this release addresses.

User story

As a [customer], I want to [action], so that [outcome].

Desired outcome

What changes for the user once this ships? Describe the outcome, not the feature.

Scope

The specific, small set of capabilities included in this release.

Non-goals

What you are explicitly NOT building yet, and why — this is what keeps scope small.

Flows

Step-by-step: what does the user do, screen by screen or action by action?

Requirements

Functional requirements (what it must do) and constraints (performance, security, compliance).

Acceptance criteria

The specific, testable conditions that mean this is done and correct.

Jobs to be done

What is this person actually trying to accomplish — the underlying job, not the feature request?

Pains

What makes that job hard, slow, expensive, or risky today?

Triggers

What event causes them to start looking for a solution right now?

Current alternatives

What do they use instead today — including manual workarounds and "doing nothing."

Buying objections

What would stop them from trying or paying for this?

Success definition

How would this specific person describe success, in their own words?

Organize by outcome, not by feature name — each column answers "what measurable change are we going after," with the specific work underneath it.

Now

Outcome: ____. Work in progress toward it: ____.

Next

Outcome: ____. Why it's next, not now: ____.

Later

Outcome: ____. What needs to be true before this becomes "next": ____.

Rule: if an item doesn't map to a measurable outcome, it doesn't belong on the roadmap yet.

Build approach

Pick one: Code-first (you write and review the code yourself), AI-assisted code (an AI coding editor/agent generates most of it, you review and ship), AI app builder (a prompt-based tool like v0/Lovable/Bolt generates a working app), or No-code (visual builder, no source code).

Backend

Do you need your own database and server logic, or does a managed backend (auth + database + storage in one) cover it?

Authentication

Build your own, or use a dedicated auth provider? Default to a dedicated provider unless auth is core to your product's value.

Hosting

Where does this deploy — a managed platform with git-push deploys, or something you operate yourself?

Analytics

How will you know if the primary user journey is working, from day one?

Rule: pick the option in each row that lets you ship the primary user journey fastest — you can always migrate off a managed choice later once you have real usage data to justify the switch.

Core entities

List each core "thing" your product tracks (e.g. User, Account, Order) and one sentence describing what it represents.

Relationships

How do entities connect — one-to-many, many-to-many? Sketch it, even as a simple list ("an Order belongs to one User").

Ownership

For each entity, who owns it — the user who created it, an account/team, or the system?

Permissions

Who can read, edit, or delete each entity? Note any role-based rules now, before they're tangled into the code.

Retention rules

What happens to each entity when a user deletes their account or cancels — deleted immediately, soft-deleted, or retained for compliance?

1. Plan — write a one-paragraph description of the change and its acceptance criteria before touching code.
2. Implement — build the smallest version that satisfies the acceptance criteria.
3. Review — read your own diff (or have an AI assistant review it) before it ships.
4. Test — verify the primary path and at least one edge case manually or with an automated test.
5. Preview — deploy to a staging/preview environment before production when the change is risky.
6. Deploy — ship to production, ideally via an automated pipeline, not a manual file copy.
7. Observe — watch error rates and key metrics for a period after deploy.
8. Roll back — know the exact rollback step before you need it, not while you need it.

Feature planning

"I want to build [feature] for [product context]. Propose the smallest implementation that satisfies this: [acceptance criteria]. List the files likely to change and any open questions before writing code."

Debugging

"Here is an error and the relevant code: [paste]. Explain the likely root cause before suggesting a fix, and flag if the fix could have side effects elsewhere."

Refactoring

"Refactor this code for clarity without changing its behavior: [paste]. Explain each change and confirm it's behavior-preserving."

Test generation

"Write tests for this function/flow: [paste], covering the primary path and the most likely edge cases and failure modes."

Review

"Review this diff as a strict senior engineer: [paste]. Flag correctness bugs, security issues, and anything that looks like unnecessary complexity."

Documentation

"Write a short, plain-language explanation of what this code does and why, for a founder who will need to maintain it without deep context: [paste]."

Audience

Who is this brand speaking to, specifically — reuse the persona from Stage 2.

Category

What category does this belong to in the customer's mind? Naming the category shapes what they compare you against.

Promise

The one thing this brand reliably delivers, stated plainly.

Differentiation

Why this over the obvious alternative — including "doing nothing."

Personality

3-4 adjectives that describe how this brand should feel, and 1-2 it should explicitly avoid.

Proof

What evidence backs the promise — data, testimonials, credentials, or demos?

Constraints

Budget, timeline, or existing assets (a name you already own, a domain you already have) that shape what's realistic here.

Colors

One primary, one accent, neutral grays, and semantic colors (success/warning/error).

Typography

One heading font (or weight) and one body font, plus a small type scale (e.g. 3-4 sizes).

Spacing

A single spacing scale (e.g. 4/8/16/24/32px) applied consistently instead of ad hoc values.

Radius

One or two corner-radius values used everywhere, not a different one per component.

Icon style

One icon set/style — outline or filled, one stroke weight — not mixed styles.

Cards, buttons, forms

Define the default look for these three recurring elements once, then reuse them everywhere instead of redesigning per page.

Accessibility

Confirm text/background contrast meets a readable minimum and interactive elements have visible focus states.

Hero

One sentence: who this is for and the outcome it delivers. No jargon.

Pain

Name the specific pain in the visitor's own language, so they recognize themselves immediately.

Outcome

What changes for them after using this — be concrete, not aspirational.

Workflow

A short, visual walkthrough of how it actually works, in 3-4 steps.

Proof

Testimonials, usage numbers, logos, or a live demo — whatever you actually have.

FAQ

Answer the 4-6 questions visitors actually ask before buying, including pricing and setup effort.

Objection handling

Directly address the top 1-2 reasons a skeptical visitor wouldn't convert.

CTA

One primary action, repeated at the top and bottom of the page — not multiple competing buttons.

Use this as a reusable system prompt so any AI-assisted copy — landing page, emails, support replies — stays on-brand:

"You are writing copy for [product name], a [one-line description] for [target audience]. Voice principles: [e.g. direct, plain-spoken, no hype]. Always: [e.g. use 'you', short sentences, concrete numbers over adjectives]. Never: [e.g. superlatives like 'best-in-class', exclamation points, jargon like 'synergy' or 'leverage']. Here are two examples of on-voice copy: [paste 2 real examples]. Before finalizing any copy, check it against this list: does it sound like a real person, is every claim specific and true, would the target audience actually talk this way?"

Update the bracketed sections once per brand, then reuse the same prompt everywhere copy gets written.

Week 1 — Preparation

Finalize product stability, launch assets, and submission dates. Line up 5-10 people who'll engage on launch day.

Week 2 — Soft launch

Ship to a small warm audience (existing waitlist, community, friends). Fix anything that breaks before the public push.

Week 3 — Public launch

Execute the scheduled directory/community submissions and social posts. Monitor analytics and support closely all day.

Week 4 — Follow-up and review

Send follow-up email/social content to people who engaged but didn't convert. Run the launch review and record what you'd repeat or change.

Track every launch channel in one table so nothing gets submitted twice or forgotten:

Fill one row per directory/community/channel before Week 1 ends, so Week 3's submissions are execution, not discovery.

1. Waitlist

"We're building [product] to solve [problem]. Join the waitlist to get early access and shape what we build."

2. Announcement

"We're live. [Product] does [core value] for [audience]. Here's how to get started: [link]."

3. Value demonstration

Show, don't tell — a short walkthrough of the core workflow, or a before/after example.

4. Proof

Share an early testimonial, usage number, or case study now that you have real users.

5. Reminder

"Haven't tried [product] yet? Here's the fastest way to see the value in under 2 minutes." Target non-openers/non-clickers from earlier emails.

6. Feedback

"What's one thing that would make [product] more useful to you?" — ask directly, and make replying effortless.

Founder story

"I built [product] because [personal reason tied to the problem]. Today it's live: [link]."

Problem

Open with the pain point in the audience's own words before mentioning your product at all.

Demo

A short screen-recording or GIF showing the core workflow in under 30 seconds.

Build-in-public

Share one specific number or lesson from building this (users, revenue, a mistake you fixed).

Proof

Quote or screenshot a real piece of user feedback, with permission.

Ask

A direct, low-friction ask: try it, share it, or answer one specific question.

Summary

A 2-3 sentence description of the product anyone could copy-paste into an article.

Founder bio

A short, factual bio — 2-3 sentences, no superlatives.

Screenshots

3-5 clean, high-resolution screenshots of the core product experience.

Logos

Logo files in a few common formats/sizes, on transparent background.

Facts

Founding date, team size, funding status (if any), and any notable numbers.

Links

Website, product page, and primary social profile.

Quotes

1-2 pre-approved founder quotes a journalist or creator can use directly.

Contact details

A real email a journalist or creator can reach, monitored during launch.

Run this loop every week rather than treating acquisition as a one-time launch push:

1. Pick one channel experiment for the week (a specific outreach list, community, or content format) — not five at once.
2. Send personalized outreach to a specific list, logged in your tracker.
3. Publish one piece of content tied to the problem you solve, not generic company news.
4. Participate in one community with genuine value, not a pitch.
5. Offer live demos to anyone who shows real interest — don't wait for them to self-serve.
6. Collect feedback from every interaction, win or lose, into one place.
7. Review the week: what worked, what didn't, what to double down on next week.

Problem interview request

"I'm researching how [role] handle [problem]. Would you have 15 minutes to share how you deal with it today? No pitch — just trying to understand it better."

Warm introduction

"[Mutual contact] mentioned you deal with [problem] — I've been building something in this space and would love to get your take."

Cold outreach

"Noticed [specific, researched detail about them]. I built [product] to solve [problem] for people like you — worth a quick look?"

Follow-up

"Following up in case this got buried — still happy to show you [product] if useful, no pressure either way."

Demo invitation

"Want to see [product] in action? I can walk you through it in 15 minutes, whenever works for you: [scheduling link]."

One row per lead or conversation — the point is having a single source of truth instead of memory or scattered DMs:

Review this weekly during the First 100 Users playbook loop — it's how you spot which channel and message actually convert.

Communities

List the 2-3 communities where your actual target customer already spends time.

Norms

What's acceptable there — self-promotion rules, tone, format expectations? Read them before posting.

Value contribution

What can you genuinely contribute before ever mentioning your product — answers, resources, feedback on others' work?

Content format

What format performs in this community — long-form posts, quick answers, threads?

Cadence

How often will you show up, realistically, so you build recognition rather than appearing once and vanishing?

Learning

What are you tracking to know if this community is actually converting into users, not just activity?

Feedback

"You've been using [product] for a bit now — what's one thing that's been genuinely useful, and one thing that's been frustrating?"

Proof

"Would you be open to sharing a quick quote about your experience? Even a sentence or two would help a lot."

Case study

"Your results with [product] stood out — would you be up for a short call so I can write up how you're using it?"

Referral

"Do you know anyone else dealing with [problem] who might get value from this?"

Permission

"Okay if I share what you said (with/without your name) on the site or in marketing?" — always ask explicitly before publishing.

List every recurring task before automating anything — this is what keeps you from automating the wrong thing first:

Rule: automate high-frequency, low-sensitivity tasks first. Anything touching money or irreversible customer actions gets a human approval gate, not full automation, until it's proven.

1. Classify — sort the incoming message by type (bug, question, billing, feature request).
2. Answer — resolve directly from a known-answer library when confidence is high.
3. Request context — ask a clarifying question when the issue is ambiguous, rather than guessing.
4. Escalate — route to the founder/human for anything sensitive, angry, or outside the known-answer library.
5. Log — record every ticket and its resolution in one place, regardless of channel.
6. Learn — feed recurring issues back into the product roadmap or the known-answer library.

1. Enrich — pull company/person data automatically when a lead comes in.
2. Score — apply a consistent rule against your ideal-customer profile.
3. Reject — automatically filter out clearly-unqualified leads rather than manually triaging every one.
4. Nurture — route not-yet-ready leads into a lightweight automated follow-up sequence.
5. Route — send qualified leads to the right owner (you) immediately, not in a weekly batch.
6. Follow up — trigger a reminder if a qualified lead goes untouched past a set window.
7. Record — log the outcome in the Lead and conversation tracker either way.

1. Signup — welcome email with the single most important next step.
2. Activation — triggered once the user hits your defined "aha" moment.
3. Inactivity — triggered after a set period of no usage, with a specific reason to come back.
4. Upgrade — triggered when usage approaches a plan limit or a clear upgrade signal appears.
5. Renewal — reminder ahead of a billing renewal, especially for annual plans.
6. Failure — triggered on a failed payment, with a clear, low-friction way to fix it.
7. Cancellation — triggered on cancellation, asking why (and offering a save option if appropriate).
8. Return — triggered if a cancelled user shows renewed interest (visits pricing, opens old emails).

For every automated or AI-assisted action in the business, classify it into exactly one bucket — this is what keeps automation from silently making a decision it shouldn't:

Execute automatically

Low-risk, easily reversible, high-volume — e.g. sending a receipt email, tagging a support ticket.

Draft for human review

Medium-risk or customer-facing — e.g. a support reply the founder approves before sending.

Recommend only

The system suggests an action but a human decides — e.g. "this lead looks worth a call."

Escalate immediately

Anything ambiguous, angry, legal, or unusually high-value — routed straight to a human, no automated attempt first.

Never automate

Irreversible, money-moving, or identity-sensitive actions — refunds above a threshold, account deletion, contract terms — always require a human to act.

One number per row, reviewed on a fixed cadence (weekly is typical for a solo founder):

Keep this to one screen — a scorecard you stop checking because it's too long is worse than no scorecard.

Wins

What genuinely went well this month — specific, not vague.

Misses

What didn't go as planned, without spin.

Metrics

Pull the KPI scorecard trend for the month.

Insights

What did the data or customer conversations teach you that you didn't know a month ago?

Customer evidence

Direct quotes, tickets, or interview notes that back up (or challenge) your current plan.

Risks

What could derail next month if left unaddressed?

Decisions

What are you changing based on this review — be specific and time-bound.

Next bets

The 1-3 things you're prioritizing next month and why.

One row per experiment — the discipline is writing the hypothesis and guardrail down BEFORE you look at results:

A guardrail metric is something that must NOT get worse (e.g. support tickets, churn) even if the success metric improves.

Impact

Who and what was affected, and for how long?

Timeline

What happened, in order, from first symptom to resolution?

Detection

How did you find out — monitoring, or a user reporting it? (If a user found it first, that's itself a finding.)

Root causes

What actually caused this — not just the immediate trigger, but the underlying gap that allowed it.

Response

What did you do to mitigate or fix it, and how long did that take?

Fixes

What's changing in the product or process as a direct result?

Prevention

What would need to be true for this specific failure to be impossible (or caught immediately) next time?