whawkinsiv/solo-founder-skills

# About Me

Create `ABOUT-ME.md`: a short file that captures how the founder writes, what they know, and what they believe. Skills that write in the founder's voice read it: content, first-customers, landing-page, and humanize.

The brain dump is itself a voice sample. Analyze how the founder writes, not only what they say.

## Steps

### If ABOUT-ME.md exists

Ask what changed. Update those sections. Do not start over.

### Step 1: Collect the brain dump

# Beautify

Make the app look intentionally designed instead of generated, and make every screen handle real data. Restraint is the main tool: fewer colors, fewer weights, fewer borders, fewer shadows.

Read `references/ai-slop-fixes.md` for the 12 patterns AI-generated interfaces fall into and how to fix each one. Examples there use Tailwind class names. Translate them to the project's own styling.

## Choose the mode

- **Direction:** a new app with no visual style yet. Do Step 1.
- **Build:** a new screen. Apply the rules in Steps 2–4 while you build.
- **Review:** existing screens. Do Step 5.

## Step 1: Set a direction (once)

# Build

Build the smallest version that paying customers need, one piece at a time. Every piece is tested before the next one starts.

## Step 1: Check the gate

Ask: "How many people pay for this today, and do you deliver it by hand now?"

- **Paying customers and written manual steps:** continue.
- **No paying customers:** say once, plainly, that building first is the most common way founders lose months, and suggest the manual delivery test in **validate** and **first-customers**. If the founder still wants to build, build. It is their decision.

## Step 2: Scope the first version

Start from the founder's written manual steps, if they exist. The first version automates **the one step that takes the most time per customer**. Every other step stays manual, or uses a tool the founder already has: a form, a spreadsheet, a payment link, email.

# Content

For a solo founder, content is the marketing department. The goal is customers, not followers. Publish what only this founder can write, on one platform, for long enough to work.

Read ABOUT-ME.md first. If it does not exist and the piece must sound like the founder, suggest **about-me**.

## Step 1: Pick one platform

Go where the customers already talk about the problem. Search the problem's keywords on each likely platform (LinkedIn, X, Reddit, YouTube, a niche forum, a newsletter). The one with the most active discussion wins.

One platform, done well, for 3 months before judging. A weak presence on five platforms loses to a strong presence on one.

## Step 2: Choose what to write about

# Naming a product and getting the domain

A name can fail in two ways: it is a bad name, or it is a good name you cannot have. Judge the concept first. Test availability second.

## Optimize in this order

```
great concept  →  great name  →  acceptable domain
```

**Never the reverse.** The failure is subtle: one pattern starts returning free domains, so you generate more of that pattern, and within two rounds availability is choosing the concept. The symptom is a list where most names share a word or a shape.

A great name with an acceptable domain beats a mediocre name with a perfect one. `Foothold` on `getfoothold.com` works. `socialengagementautomation.com` is still a dead name. When a strong name's exact domain is gone, try other suffixes in the acceptable set and the `get`/`use` + one word wrapper (rules 7 and 10 in the scorecard) before dropping the name. Drop a name for being weak, never for being taken.

# Email

Set up `hello@yourdomain.com` before the first outreach. A message from a personal webmail address reads as a side project. One that lands in spam is never read.

## Step 1: Receive mail at the domain

Forward `hello@` to the founder's existing inbox. Many DNS providers and registrars offer free forwarding (for example, Cloudflare Email Routing). Add aliases for `support@` and `billing@` that forward to the same inbox, and filter them by label.

## Step 2: Send as the branded address

Pick one option:
- **Free:** add the address in the inbox's "send mail as" setting, through the SMTP relay of a transactional email service. Verify the domain in that service first.
- **Paid and simpler:** a hosted mailbox on the domain (Google Workspace, Fastmail, or similar). Choose this when the founder wants less setup, needs calendar invites from the branded address, or adds a second person.

# Finances

For a bootstrapper, runway is the main limit. Know three numbers: how much the founder needs, how long the money lasts, and whether revenue passes costs before it runs out.

## Step 1: The quit number

```
Monthly personal costs (rent, food, insurance, debt, other) + 20% buffer = monthly need
Revenue needed per month = monthly need ÷ 0.70     (covers tax, tools, and variance)
Customers needed         = revenue needed ÷ price
Timeline                 = customers needed ÷ realistic new customers per month
```

Show the timeline plainly. If the founder needs 500 customers at \$29, that is likely a journey of 18–36 months. **pricing** shows how a higher price shortens it.

# First Customers

Sell one person at a time. Get the first 10 paying customers by hand. Then grow to 100. Most early growth comes from direct outreach, not from a launch.

Read ABOUT-ME.md first, if it exists. Outreach should sound like the founder.

## Step 1: Contact people in this order

Each group is harder to sell to than the one before. Learn the pitch where mistakes cost least.

1. **People the founder knows who have the problem:** former colleagues, past clients, professional contacts. Ask them to buy, not to share a post. Friends and family can buy, but do not count them toward the first 10. They pay to support the founder, not to solve a problem.
2. **Communities the founder already belongs to:** forums, groups, associations, Slack or Discord servers. List everyone there who has talked about the problem, and contact each one personally.
3. **Strangers with a pain signal.** Use the prospect list in Step 2.

# Focus

Judge one activity, one decision, or one feature choice against the founder's stage. Return one verdict and one plan for this week.

## Step 1: Get the facts

Ask only what you cannot infer. Two or three questions:
- What exactly is it? Not "marketing", but "50 cold emails a week to dental offices."
- How many paying customers do you have?
- For an activity: hours per week, and results so far. For a decision: the cost, and whether you can undo it.

Then use the mode that fits.

## Mode A: An ongoing activity

# Go Live

A gate, not a process. Check the app the way a stranger with a credit card would meet it. Pass, and the founder lets customers in. Fail, and the founder fixes the showstoppers first.

## Step 1: Deploy, if not live yet

- Use a managed host that deploys from git, so every push deploys.
- Production has its own environment variables, set in the host's dashboard or CLI, and its own database, separate from development.
- Connect the custom domain at the host. The host lists the DNS records to add.
- Skip a staging environment until there are paying customers.
- The first deploy should take under 30 minutes. If it takes hours, simplify.
- "Works locally, broken in production" is usually a missing environment variable. Check those first.

## Step 2: Showstoppers (all must pass)

# Humanizer: Remove AI Writing Patterns

You are a writing editor. You find signs of AI-generated text and remove them. The text must then read like the writer, not like a chatbot.

**Why this matters:** Customers, investors, and Google can all spot AI-written text. It erodes trust. If your landing page, blog post, or email sounds like ChatGPT wrote it, people assume you did not care enough to write it yourself. This skill fixes that.

**This skill edits text that already exists.** To write new pieces, use **content** or **landing-page**.

> **If `ABOUT-ME.md` exists in the project root**, read the Communication Style section before you edit. "Human" does not mean generic human. It means this specific person. Match their sentence rhythm, vocabulary, humor, and opinions.

## Hard rules

**1. Do not invent facts.** Do not add a fact, name, number, date, quote, citation, or ranking unless the source text or the user supplies it. This rule has no exceptions outside fiction.

# Is this an app?

Not every idea needs to be a full web app. This skill scores a new idea on a 14-dimension weighted matrix and recommends the form the idea should take, before the founder builds anything.

## Step 1 — Get the idea

If the founder has not described the idea, ask what it does, who it is for, and how they will use it.

## Step 2 — Score the matrix

Read `references/matrix.md`. Score each of the 14 dimensions 0–5 against its anchors. Use the test question for each dimension to score consistently.

If you cannot score a dimension from what the founder said, ask. If the founder wants an answer now, make your best guess and mark that score as a guess.

# Journey

Find the founder's stage and name the one next step. The stage depends on paying customers, not on how much code exists.

## The order

Sell before you build. Get the first 10 paying customers by hand, then grow to 100.

| Stage | The founder says | Use | Gate to pass before the next stage |
|---|---|---|---|
| 0. No idea | "I don't have an idea yet" | **validate** (find the problem) | One problem that people they can name have now |
| 1. Idea | "I have an idea" | **validate**, then **is-this-an-app** | Evidence that strangers have the problem and spend money or time on it |
| 2. Sell by hand | "How do I get my first customers?" | **pricing**, **landing-page**, **email**, **first-customers**, then the manual delivery test in **validate** | 10 paying customers who are not friends or family, and the delivery steps written down |
| 3. Build | "Now I build it" | **build**, **beautify**, **secure** | The step that takes the most time is automated, and customers use it |

# Landing Page

A landing page is a sales conversation, not a brochure. Early on, its job is to get a stranger to **pay, pre-order, or book a call**. A waitlist sign-up is only for a demand test in **validate**.

## Step 1: Gather the material

Read ABOUT-ME.md and any validation brief or customer notes in the project. Then ask for what is missing:
- the offer in one sentence: what the customer has before, and after
- the price, or the price range
- the one action: pay, pre-order, or book a call
- the customer's own words for the problem: quotes from conversations, posts, or reviews
- the real proof the founder has: paying customers, results, quotes given with permission, or the founder's own experience in the field

## Step 2: Write the page in the order the buyer asks questions

# Legal

Get the few legal pieces a solo software business needs at launch, and skip the rest until a customer or a law requires them.

Everything this skill writes is a first draft, not legal advice. A licensed lawyer reviews anything binding before it is published. Paying a lawyer \$500–1,000 to review a draft costs far less than paying for the draft itself.

## Step 1: Choose the entity

These rules are for the US. Elsewhere, ask about the local equivalent of a limited-liability company.

```
Plans to raise venture capital?     → Delaware C-Corp
Profit above about \$60K a year?    → LLC, then talk to an accountant about S-Corp tax treatment
Otherwise                           → LLC in the founder's home state

# Payments

Take money with the least code that works. Stripe is the default for a solo founder: hosted checkout, a hosted billing portal, and good test tools.

## Stage 1: The first customers

Use a **Stripe Payment Link** or an invoice. No billing code. The founder grants access by hand after each payment. This works for the first 10 customers and often longer. Build billing in the app when granting access by hand starts taking real time.

## Stage 2: Billing in the app

1. **Create products and prices in the Stripe Dashboard,** not in code. Reference them by price ID or lookup key.
2. **Use Stripe Checkout** (the hosted payment page). Do not build a card form.
3. **Use the Customer Portal** for card updates, plan changes, cancellations, and invoices. Do not build a billing page. Set cancellation to happen at the end of the billing period, and turn on the cancellation-reason question.
4. **Store each customer's subscription status in the database,** updated only from webhooks.

# Pricing

Charge from the first customer. A free user tells you they like free things. A paying customer tells you the problem is worth money.

## Step 1: Find the stage

Ask how many people pay today. Before 10, use Step 2. From 10 on, use Step 3.

## Step 2: Before 10 paying customers

1. **Set one price.** No tiers, no free plan. Base it on what the customer spends on the problem today, in money or in hours multiplied by their hourly rate. Your costs set the floor, not the price.
2. **Check the anchor.** What do these customers already pay for tools? A \$49 add-on feels small to someone paying \$300 a month for software, and large to someone who pays nothing.
3. **Do the customer math with the founder:**
   ```

# Retention

Before 100 customers, keeping customers is personal work, not automation. Talk to every customer, fix what they hit, and tell them when you did.

## Step 1: Get every new customer to the first result

1. **Define the first result:** the first action where the customer gets what they paid for. Examples: the first invoice sent, the first report seen with their own data.
2. **Before about 20 customers,** onboard each one yourself: a short call, or a written walkthrough sent the day they pay. Watch where they get stuck.
3. **After that,** add a short welcome email series that stops as soon as the customer reaches the first result:
   - right away: one action to take, and nothing else
   - day 1 and day 3, if not done yet: how to get there in 2 minutes
   - day 7: a personal note from the founder: "Reply to this. I read every one."
4. In the product, an empty screen shows the next step (see **beautify**).

# Secure

Run a security audit on the codebase and fix what matters first. AI-built apps fail in a few predictable places. Check those places, prove each finding, and fix it.

## Step 1: Map the app

Read the code and list, briefly:
- the framework, and where the server code runs
- the database, and whether the browser talks to it directly
- how users log in
- every API route, server action, and webhook endpoint
- every third-party key the app uses
- every call that costs money: AI models, email, SMS

# SEO

Audit the codebase for search and AI-answer visibility, then fix what matters. Give a prioritized plan of concrete changes, not a lecture on SEO.

**Set expectations first.** SEO takes 3–6 months to bring traffic. It is the free channel that compounds for a bootstrapper, but it will not bring customers this week. For customers now, use **first-customers**.

## Step 1: Understand the project

1. Read CLAUDE.md or README to learn what the product is and who it is for.
2. Identify the framework, so you know where templates, routes, and metadata live.
3. Map the site structure from the top 3 levels of the directory tree.

## Step 2: Audit

# Validate

Find out whether strangers will pay for this, as cheaply as possible. The goal is to fail fast, not to confirm what the founder already believes.

```
find   →  pressure-test  →  design       →  run            →  verdict
(no idea  (is the idea      (cheapest       (the founder      (score the
 yet?)     coherent?)        test of the     does this)        evidence)
                             biggest gap)
```

Most founders want the verdict without the evidence. Route them back to the earliest stage they have not finished.

## Step 0: Context