Core concepts

You solve a problem you have yourself, in work you already do. You do not have to guess what hurts, because it hurts you. Every design decision gets tested against a real user the same day you make it.

1. Write down the three things that annoyed you most in your own work this month.
2. Pick the one you have already tried to fix with a spreadsheet or a manual workaround.
3. Build the smallest version that replaces your workaround, and use it yourself daily.
4. Only then ask whether anyone else has the same workaround.

You choose a specific group and aim to delight them rather than reach everyone. Serving everyone means being interchangeable. Serving a narrow group means people can tell each other exactly who you are for.

1. Name the group in one sentence: who they are and what they are trying to do.
2. Make the offer specific enough that the wrong person self-selects out.
3. Optimise for people telling peers, not for reach.
4. Widen only after the narrow group is well served.

A painkiller removes something the buyer already hates and already spends time or money on. A vitamin is a nice improvement they can postpone forever. Vitamins get praise; painkillers get invoices.

1. Ask whether the buyer is already paying, in cash, hours, or workarounds, to avoid this problem.
2. Check that the pain recurs. One-off pain does not sustain a business.
3. Test it by asking for money early, not by asking whether people like the idea.

You put up the offer and the price before the product exists, and see whether anyone tries to buy. A signup form tells you people are curious. A click on a pricing plan tells you they are buyers.

1. Write the page as if the product shipped yesterday. Be specific about what it does.
2. Put a real price behind a real button.
3. Count the people who reach the payment step, not the people who read the page.
4. Build only if the number is enough to matter to you.

Instead of interviewing people about hypotheticals, you go and read what they already wrote when nobody was selling to them, forums, reviews, support threads, replies. You are collecting evidence of pain, and the exact language to describe it.

1. Find three places your buyers talk to each other, not to vendors.
2. Collect complaints, workarounds, and the tools they curse at. Quote them verbatim.
3. Look for the pain that appears three or more times from different people.
4. Write your landing page using their words, not yours.

You are the first and most demanding user. Anything broken, slow, or confusing costs you personally, so it gets fixed. It also means you keep a permanent, honest picture of what the product is actually like to use.

1. Move one real workflow of yours onto the product, with no fallback.
2. When something annoys you, log it the moment it happens.
3. Fix the thing that annoyed you three times this week, not the thing on the roadmap.

Every plan rests on assumptions. One of them is load-bearing: if it is false, nothing else matters. The job of the first build is to test that one thing as cheaply as possible, which is often not a product at all.

1. List what has to be true for this to work.
2. Mark the one that would end the project if it were false.
3. Design the cheapest honest test of that single belief, a video, a page, a manual service.
4. Run it before building anything else.

Solo, every piece of infrastructure is something you personally maintain, upgrade, and fix at bad times. Interesting technology spends your only non-renewable resource, attention, on problems your customers never asked about.

1. Prefer tools you already know over tools you would have to learn.
2. Count the moving parts. Every service you add is a thing that can page you.
3. Optimise for how fast you can fix it, not how fast it runs.

You cannot reason your way to the right product. You can only ship, watch, and adjust. A founder who ships twelve times learns twelve things; a founder who polishes one thing for a year learns one.

1. Fix the interval, weekly, monthly, and flex the scope to fit it.
2. Ship something visible to real users every interval, however small.
3. Judge each release on what it taught you, not on how finished it felt.

Solo, automation is your headcount. But a big automation that does five things fails in five ways and is impossible to reason about. Many small jobs, each with one responsibility, fail loudly and independently, and you can replace any one of them in an afternoon.

1. Write down the repeating task in one sentence. If it needs an "and", it is two jobs.
2. Give each job one input, one output, and one place it reports failure.
3. Let jobs hand off through data, not by calling each other.

Most founders assume a good enough product will be discovered. It will not. Getting one channel to work reliably is a harder and more valuable achievement than shipping the feature, and it takes the same kind of deliberate work.

1. Choose one channel and commit to it long enough to get a real answer.
2. Give it the same budget of hours you would give a feature.
3. Measure whether it delivers buyers, not attention.
4. Only add a second channel once the first one works.

A furniture maker produces sawdust whether or not they sell it. Building a company produces decisions, numbers, failures, and small techniques, all of it publishable. You are not adding a content job; you are opening a window onto the job you already have.

1. Keep a running log of decisions, numbers, and things that broke.
2. Once a week, publish the most useful entry with the real detail left in.
3. Do not sand it into a marketing piece. The specificity is the value.
4. Let it accumulate. Individually these are small; collected they are a reason to trust you.

Most launches fail quietly because nobody was listening. If you spend the build period teaching what you know, you arrive at launch with people who already trust you, and with a much better idea of what to build, because they told you.

1. Teach what you already know, publicly and consistently, before you have anything to sell.
2. Collect the audience somewhere you own, email, not a follower count.
3. Ask them what is hard. Build that.
4. Sell to the people who were already listening, then ask them who else to talk to.

Followers, rankings and API access are rented. The landlord sets the rules, changes them without notice, and owes you nothing. Email addresses and your own domain are the only distribution you actually hold.

1. Use rented reach to find people, then move them somewhere you own.
2. Treat every platform as temporary, however well it is working right now.
3. Ask what happens to revenue if any single platform disappears tomorrow. Fix the worst answer.

Treating launch as a single day puts everything on one roll of the dice, and the traffic decays within a week. Treating it as a repeating event means every meaningful change is a reason to show up again, in front of people who missed you the first time.

1. Define what counts as launchable: a feature, a milestone, a public number, a teardown.
2. Ship it somewhere public on a schedule you can keep.
3. Reuse what worked and drop what did not, each round is also a channel test.

Free signups measure curiosity. Payment measures whether the problem is real enough to spend on. Charging early also selects for the customers worth listening to, and it means the business is a business from the start rather than a bet on later conversion.

1. Price the first version, even if the price is low and the product is small.
2. Treat the first ten paying customers as the research, not the revenue.
3. Raise the price when the value is proven, rather than starting free and hoping.

It is a single question about the trajectory you are already on. If current growth gets you to profitable before the cash is gone, you are default alive and you have choices. If not, you are default dead and you are dependent on someone else saying yes.

1. Take current revenue, current growth rate, current spending, current cash.
2. Extend the line. Does it cross before the cash hits zero?
3. If not, the fix is either cost or growth, decide which, early, while both are still possible.
4. Recheck whenever spending changes.

Ramen profitability means the business makes enough to pay for your basic living expenses. It is a low bar financially and an enormous one strategically: past it, nobody can shut you down by declining to fund you, and you can keep going until something works.

1. Write down what you actually need per month to live. That is the target.
2. Compare it to current revenue. The gap is the only number that matters right now.
3. Close the gap before you optimise anything else.

Subscriptions feel like growth because new customers are visible and cancellations are not. But every month churn removes a slice of the base you already paid to acquire. Past a certain rate, acquisition is just refilling a bucket with a hole in it.

1. Track cancellations as a rate, next to signups, on the same screen.
2. Ask every leaver one question, and read the answers yourself.
3. Fix retention before spending more on acquisition, the leak scales with the growth.

Solo, you cannot absorb a single large failure the way a funded team can. A portfolio of small, cheap attempts means any one of them can fail without ending you, and you only double down when something shows a real signal.

1. Keep each bet small enough that failure costs weeks, not years.
2. Reuse the same stack and the same audience across bets so the effort compounds.
3. Commit further only where there is a signal, not where there is hope.

Capital and staff are permissioned, someone has to give them to you. Code and media are not: you can write both today, and they keep working afterwards at close to zero cost per additional user. For a solo founder this is the only leverage available on demand.

1. Ask of each task: does this produce an asset that keeps working, or does it end when I stop?
2. Move time from repeated manual work toward code and writing.
3. Accept that leveraged work has slow starts and long tails.

With one pair of hands, agreeing to something is not addition, it is substitution. The cost of a yes is invisible because the displaced work simply never happens. Making no the default forces that cost into the open.

1. Default to no. Let good ideas be asked for twice before they get in.
2. When you say yes, name out loud what it pushes out.
3. Fix the time and flex the scope, rather than the other way around.

At the start you have very few users, so you can afford to serve each one by hand. Doing so teaches you things no analytics dashboard will, and it converts early users into people who stay. Automation built before that knowledge automates the wrong thing.

1. Recruit the first users personally, one at a time.
2. Do the work manually behind the scenes before you write code for it.
3. Deliver an experience that would be impossible at scale, that is the point.
4. Automate only the parts you have now done by hand often enough to understand.

In the middle of a project you are the worst possible judge of whether to continue, because you have already spent the effort. Setting the stopping condition in advance, while you are still neutral, is the only reliable protection against projects that never quite die.

1. Before starting, write the metric and the date: “if not X by Y, I stop.”
2. Make it specific enough that it cannot be argued with later.
3. When the date arrives, honour it or explicitly renew it, never drift.
4. Shut down publicly. It frees the attention and it is honest.

In a one-person company there is no redundancy. If you stop, everything stops, so your capacity to keep going is infrastructure. Working at a pace you can hold for years is not comfort; it is the thing that lets compounding happen at all.

1. Set hours you can hold indefinitely, then fit the work into them.
2. Treat a crunch as a planning failure to fix, not a sacrifice to repeat.
3. Protect the inputs, sleep, attention, people, as operating expenses.