New here? Start here.

Language models are excellent at turning something vague into something structured: a messy paragraph into a plan, a plan into tasks, a task into working code. They read faster than you, write faster than you, and never get tired of the boring parts.

They are also good at showing you what you did not think of. Ask what is missing from a plan, what could go wrong, or how someone hostile would read your landing page, and the answer is usually worth the minute it took.

What has genuinely changed is the cost of building. Something that took a small team three months can now take one person two weeks. That is real, and it is why this is worth doing at all.

A model knows what was written down and published, up to some point in the past. It does not know what happened last month, what your competitors changed yesterday, or what people in your city are actually willing to pay.

It does not know your constraints unless you tell it: how much time you have, how much money you can lose, what you are not willing to do, who else is involved. Without that, its advice is written for an imaginary person with unlimited time.

And it does not know what it does not know. There is no internal signal that says "I am making this part up". That is why anything load-bearing gets checked against a source.

A model produces the most plausible continuation of the text so far. Plausible usually means correct, because correct things are usually plausible — but when it does not know, the machinery does not stop. It produces something equally fluent and equally confident that happens to be invented.

This is why fabricated statistics, invented sources, and features of a product that does not have them all read exactly like the true parts. There is no change of tone to warn you.

The practical rule: the more a claim would change your decision, the more it needs a source you can open. A number, a competitor's price, a legal requirement, a market size — check it. An explanation of how something generally works — usually fine.

Ask a model whether your idea is good and it will almost always find a way to say yes, then list some considerations. Ask it about the opposite idea and it will say yes to that too. Both answers cost it nothing.

This matters because that "yes" feels like validation. It arrives in the same confident, articulate voice as everything else, and it arrives at the exact moment you are looking for a reason to proceed.

Real validation looks different and is harder to get: someone with the problem says they have it, describes what they do about it today, and either pays you or clearly explains why not. Everything else is preparation.

Write down the two or three statements that, if false, would make the whole project pointless. "People pay for this today." "I can reach them for less than they are worth." "This is legal for me to sell where I live." Those are the ones to verify.

Verification means a source you can open and a date you can see: a competitor's actual pricing page, a real listing, a regulator's own words, a forum thread where people describe the problem in their own words. Not a summary of a summary.

When you cannot verify something, that is not a failure — it is a finding. Write it down as an assumption, and design your first step so that it tests the assumption cheaply.

A checkable idea names a specific person, a specific situation, and what they do today instead. "Home cooks who batch-cook on Sundays and currently keep recipes in screenshots" is checkable. "People who like food" is not.

It also names the change: what becomes possible, faster, cheaper or less awful. If the answer is "it is nicer", the idea may still be worth building, but it is not yet a reason for anyone to switch.

Finally, it says what has to be true. Every idea rests on beliefs about the world. Writing them down turns an argument about taste into a list of things that can be checked.

A commercial project has to find customers who pay more than it costs to reach and serve them. That constraint governs everything: what you build, in what order, and when you stop.

A personal project does not. It can exist because you wanted it to exist, because you are learning, because it solves your own annoyance. Measuring it by revenue is like measuring a hobby by its salary.

The mistake is not choosing one — it is drifting between them. Building for yourself while quietly expecting money, or chasing revenue on something you started for fun, produces the worst of both. Decide, write it down, and change it deliberately if it changes.

Start with what people already pay for. Existing paid products are the strongest signal a market exists — a crowded field is far better news than an empty one. "No competitors" usually means no market, not an untapped one.

Then look for the problem in people's own words: forums, reviews of the tools they currently use, questions asked in public, complaints. One-star and three-star reviews of your competitors are the most valuable free research available.

Finally, talk to five people who have the problem. Not about your idea — about their last week. What did they do, what did it cost them, what did they try. If nothing they say sounds like the problem you imagined, you have learned the most useful thing you will learn all month.

Pick the single assumption whose failure would hurt most, and build only what is needed to test it. Usually that is far less than a product: a page that describes the thing and asks for an email, one workflow done end to end by hand, a spreadsheet you operate yourself.

Building is now cheap enough that it is tempting to build everything. Resist it, because the expensive part is not the code — it is the months you spend on features nobody has asked for, and the confidence they give you.

Ship something small to real people early enough that their reaction can still change what you build. Then keep the thing that they use and delete the rest.

AI-written code works and also quietly leaves things behind: exposed keys, an admin page with no login, an unprotected upload, a form that silently loses submissions, a page that breaks on a phone. None of these announce themselves.

Check the boring things: does signup work in a fresh browser, does payment actually charge, does the confirmation email arrive, what happens on a slow connection, what happens when someone types the wrong thing.

Then have something check what you cannot see. Professional Hub connects to Fix Before Launch for exactly this — a full pre-launch scan and AI application testing — because the first real user finding your broken checkout is the most expensive way to discover it.