What Not to Build This Way
Money, Health and Safety
Some categories should not be your first solo build. This is not gatekeeping — it is the shape of the consequences. Anything that moves real money: taking card details yourself, holding balances, calculating payouts. Anything touching health: symptoms, medication, anything a person might act on medically. Anything where a wrong answer hurts someone physically. In these areas the failure is not "the site looks odd". It is money gone, a person harmed, and a liability with your name on it. A prototype — a rough first version built to test an idea — proves nothing at all about safety here. You can still build near these areas safely. Hand the dangerous part to an established provider: take payments through a payment company's own checkout, rather than touching card numbers yourself. Route around the hazard instead of rebuilding it.
- Never handle raw card details yourself — redirect to a payment provider's checkout
- Health, safety and legal advice need qualified review, not a confident prototype
- Ask what the worst realistic outcome is, not whether the code runs
- Delegating the risky component to a specialist provider is a legitimate answer
Scale, Compliance and Other People's Regulations
Two more categories deserve caution. Heavy scale: something expecting thousands of users at once, large file processing, or constant background work. Prototypes are built for a handful of people and quietly assume it. They fall over, or run up costs, when that assumption breaks. Then there is strict compliance: regulated industries, children's data, health records, anything where a specific standard applies. Compliance is not a feature you can add on Sunday. It shapes where data lives, who can see it, how long you keep it, and what you must be able to prove. If someone has told you which regulation applies, that is your signal to get advice before you build, not after. Building first and retrofitting compliance is the most expensive order available.
- Prototypes assume few users; that assumption is invisible until it breaks
- Regulation shapes the design, so it cannot be bolted on afterwards
- Children's data, health records and financial records all carry specific rules
- If a standard has been named at you, get advice before writing anything
The Question That Sorts It
You do not need a list you cannot remember. One question sorts most cases. If this is wrong at three in the morning, and nobody notices for a week, what happens? A landing page shows the old price — mildly embarrassing, fixed in a minute. An internal tracker miscounts — someone spots it and you correct it. A booking system double-books — annoyed customers and an apology. Now take a tool that emails your whole customer list, or charges cards, or tells someone their test result. That is a different answer entirely. And it is the answer, not your confidence, that decides whether you should be building it alone. Confidence is not evidence. The consequence of being wrong is.
- Ask what happens if it is wrong overnight and nobody notices
- Reversible and visible failures are safe territory to learn in
- Irreversible, invisible or automatic actions are where you need help
- Your confidence is not evidence — the size of the consequence decides
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.