Build your own software without knowing how to code

• Do the steps in order. Each one needs the one before it.
• Nothing here is permanent. Every account is free to delete and every file can be undone.
• You cannot break the internet. Nothing you make is visible to anyone until you decide to publish it.
• When you get stuck, paste the problem to Claude. Copy the red text, paste it, say "this happened, fix it". That is the answer to almost every problem in this guide.

I have never written code before. Please assume I know nothing technical and explain everything in plain English.

I want to build a private system to run my business, and eventually a small public website that connects to it.

My business is: [DESCRIBE YOUR BUSINESS IN ONE SENTENCE]

Right now I keep track of things using: [SPREADSHEETS / MY HEAD / PAPER / WHATEVER IT IS]

I already have accounts with Claude, Supabase, GitHub and Cloudflare, and I have installed Git and Node.js on this computer.

Do NOT write any code yet. Instead, interview me. Ask me one question at a time about how my business actually works and what I need to keep track of. Keep asking until you genuinely understand it.

When you are confident you understand, show me a plain English list of the information we should store, and wait for me to approve it before you build anything.

You will see them. They will scroll past in the chat. You do not need to learn any of them, and you should not go away and study them before starting.

Claude creates those files, installs those tools, and maintains them for you. They are the plumbing of the house, not the house. If you ever want to know what one of them is, ask Claude in the moment: "what is package.json and do I need to care?" That is a far better way to learn it than a tutorial, because you will be looking at your own.

Before you write any code, we are going to agree the rules this project is built under.

Everything below comes from someone who built a real business system this way and had to go back and fix all of it later, at much greater cost. I want it correct from the first line instead.

Write all of this into CLAUDE.md now, in your own words, and then follow it for the entire life of this project. Tell me if any of it does not apply to what we are building, and explain why.

=== SECURITY: the part I cannot check myself ===

1. Assume the key that sits in my website is public, because it is. Anyone can read it out of the page. Nothing private may ever be reachable with that key. When you tell me something is safe, show me the proof by trying to break in as an outsider would.

2. Turn on row-level security on every table in the same step that creates it, never later. Default position for any table holding personal information: nobody can read it. We then open specific doors on purpose, one at a time.

3. A public page must never read a database table directly. Give it a dedicated function that returns only the exact fields that page needs. Never hand a whole row to a public page.

4. Never let a password, token, phone number, address, private note or internal field reach a public page, even if the page does not display it. If it is in the response, it is public.

5. Grant the narrowest possible access first and widen only when something genuinely breaks. Never grant broadly and promise to narrow later.

6. Every function that runs with elevated privileges gets locked down explicitly at the moment you create it.

7. Put two-factor authentication on my admin login as soon as the login exists, not later.

8. Delete code, functions and endpoints we stopped using. Anything still deployed is still an entrance, even if nothing points at it any more.

=== EMAIL: mistakes here reach real human beings ===

9. Never send an email to a real person while testing, under any circumstance. Set up a test address on day one and make it structurally impossible for a test to reach a real contact.

10. Anything that sends in bulk must have a practice mode that shows me exactly who would receive it. I see that list before anything sends. No exceptions, no "it is probably fine".

11. Anything a stranger types into a form gets neutralised before it appears in an email to me. Assume every form field is hostile.

12. Never let a public endpoint email an address chosen by whoever calls it. The recipient must already exist in my database.

13. Before any bulk import or data change, disable anything that automatically notifies people, then re-enable it afterwards. Say this out loud to me every single time.

=== MY DATA: I cannot undo a bad write ===

14. Never replace a large block of my content in one operation. Make targeted edits to the specific part that changes. If you are about to overwrite something wholesale, stop and show me first.

15. Before anything that changes many rows at once, show me the count and a sample of what will change, and wait for me to say go.

16. Set up automatic backups in the first week. Then make me restore from one on purpose, once, so we both know it actually works.

=== SECRETS ===

17. Set up the ignored-file protection before I paste my first key, not after.

18. Assume this code could become public one day. Never store real customer data, real bank details, real statements or real personal records anywhere in the project, not even as a test example. Use obviously fake data.

19. Add an automatic check that refuses to save my work if it spots something shaped like a real account number, key or password. Never store the real value inside the check itself.

=== STOPPING MISTAKES FROM REPEATING ===

20. When you fix a bug, never fix only the one I noticed. Search the whole project for the same shape of mistake, fix every instance, and tell me how many you found.

21. Every bug we fix gets a permanent automatic test so it cannot come back quietly. An actual check that runs, not a note in a file.

22. When something breaks, find out why. Never switch off a safety check to make an error go away. A check that is firing is doing its job.

=== DO NOT GET ME BANNED OR BILLED ===

23. Saving my work locally (committing) is free and safe. Do it constantly, after anything that works. That is my undo button and there is no downside to using it.

24. Uploading that work to GitHub (pushing) is a completely different action and is NOT free of consequence. Only do it when I explicitly say "push" or "back it up". Never automate it, never put it inside a script that runs on its own, and never more than a few times in a working session. Accounts get suspended for looking like a bot doing this, and it has already happened to me once. Treat every push as deliberate.

25. Publishing to the live website is limited. The free plan allows 500 publishes a month, so batch my changes and publish when a batch is genuinely ready, never once per small edit. If we are burning through them, tell me.

26. Anything that costs money or counts against a limit gets flagged to me BEFORE you do it, not after. That includes publishing, paid AI usage, and any service that bills by the request.

=== HOW I WANT YOU TO WORK WITH ME ===

27. I am not technical. Before you do something, tell me in plain words what you are about to do, why, and what could go wrong.

28. If I ask for something that will cause problems later, say so plainly and argue with me. Do not just agree because I asked.

29. If you are unsure, say you are unsure. Never present a guess as a fact.

30. When you finish something, tell me honestly what you did not test and what you are still unsure about.

31. Build the smallest working version first and let me use it before improving it. Never build me six things at once.

Confirm you have written all of this into CLAUDE.md, then tell me which rule you think will be hardest to keep, and why.

There are three different actions that all feel like "saving", and a beginner cannot tell them apart. They have very different consequences:

Saving locally (committing) is free and unlimited. Do it constantly. It is your undo button.

Uploading to GitHub (pushing) is not free of consequence. Doing it constantly, or letting something automated do it, looks like bot behaviour. My GitHub account was taken down for exactly this. Push a few times a session at most, and only when you mean to.

Publishing to the live site is capped at 500 a month on the free plan. Plenty, unless something publishes on every edit, which is exactly what an eager assistant will do unless you tell it not to.

Set up the Supabase database with the tables we agreed on. Walk me through connecting my Supabase account step by step, and tell me exactly what to click and what to copy. Then put a few rows of fake example data in so I can see it working.

Now build me one private web page that shows that information in a clean table, and lets me add, edit and delete rows. I want to run it on my own computer first, before anything goes on the internet. Tell me exactly how to open it.

This works. Now help me put it online with Cloudflare Pages, and put it behind a login so only I can see it. Walk me through every click, and tell me what to do if something fails.

Now build a public page where someone who is not me can fill in a form, and have their answers arrive in my database automatically. Make sure nobody can see anyone else's information.

Set up email so my system can send messages automatically. Explain my options first, tell me which one you recommend for someone at my size and why, and then set it up with me.

Now set up something that runs on a schedule without me doing anything, even when my computer is off. Start with one simple example, like a reminder email that goes out every morning.

From now on, whenever I correct you, or tell you a rule about how this project works, or you make a mistake we have to fix, add it to CLAUDE.md in your own words along with why it matters. Do this immediately when it happens, not at the end of the session. If you notice you are about to break a rule that is already in there, say so out loud instead of quietly doing it.