Why most builds stall

Most micro-SaaS attempts do not fail dramatically. They stall. The repo goes quiet, the domain renews once, and eighteen months later you tell someone you used to work on a thing. Five ways that happens.

You build for small businesses, or creators, or students. Those are not customers, they are census categories. There is no room to walk into and no sentence that lands.

The mechanism: marketing a narrow product is a conversation with a person who has the problem. Marketing a broad one is advertising, and advertising costs money you do not have and skill you have not built.

Four months of evenings, a real working product, and then the first real conversation - which reveals that the people you built for already route around the problem for free, or that whoever feels the pain has no authority to spend money on it.

Building is comfortable. Asking is not. So the asking waits until it is too expensive to hear the answer.

Every feature is not one job. It is code to write, a way for the app to break, a thing to explain, a thing to support forever, and a row in a settings screen you now maintain. Scope does not grow linearly, and one person's evenings do not grow at all.

If you refuse to make version one smaller on purpose, the calendar makes it smaller for you by making it never.

Motivation has a shape. Week one is easy. Week six is flat. Month three is where the project meets a boring problem - deployment, billing edge cases, a database migration - with no user waiting on the other side to make it feel worth it.

The counter-move is structural, not emotional. Get a named human waiting before month three arrives. Owing something to a specific person is a stronger engine than wanting something for yourself.

It launches, gets posted somewhere, a handful of people look, and the conclusion drawn is that the product is bad. Usually it is untested: building is maybe a third of the job, and the rest is telling people it exists and keeping the ones who arrive.

A paying customer can email you, and will. Support load scales with the number of customers, and revenue scales with customers multiplied by price. So the ratio you actually live inside is set by the price, not by the size of your userbase.

That is the mechanism behind a rule you meet again in the pricing lesson: a cheap product with many customers is a harder life than a dearer product with few. Same money, many more inboxes.

• Pick a niche you are already inside, so the room to walk into already exists.
• Talk to five people before you write a line of code, and write down what they say rather than what you heard.
• Decide what you will not build, in writing, before you start.
• Get one named person waiting on you, with a date.
• Price so that a small number of customers is enough to matter.