3 Make a project in a nutshell

Nowadays, anyone can make LLMs write code. Even a donkey. But if you want people to use it, what will happen to their data, security, or user experience? Please know what you are doing. <3

Anyways, to make a project you need to find a problem. Because people won't use a solution to a problem that doesn't even exist.

Say your dorm has four washing machines, and you keep walking down with your basket to find all of them full. That might be a problem. Before you build anything, ask your friends about the last time it happened to them. What did they do? Did they go back up, wait, leave their clothes in a pile? Do not ask whether they like your app idea. People can like an idea they will never use. If nobody remembers the last time, the problem may not be there.

Plan it

Take the pen and paper again. Write the problem in one sentence. I walk down to the laundry room and all the machines are full. Write who has it. The people in my dorm. Write the one thing they will do in your project. See which machine is free, and say I am using this one.

Then write what the first version will not have. No payments, no chat, no notifications yet. The first version answers one question. Does seeing the machines from your room actually save you the walk? If it does, you add the rest later.

Draw the screens. A list of machines, free or busy, and a button to start using one. Then write what the app has to remember. The machines, who is using which one, and until when.

Before you ask the agent to build it, there are small things you need to know. I call them prerequisites. You do not need to be an expert in them. You need to know enough to check what the agent made.

Database prerequisite

A database is where your app keeps the things that change while people use it. The laundry app keeps the machines and who is using them.

Before you ask for a database, write what you will store as small tables. A machines table with a name and a floor. A usage table with the machine, the person and the time it ends. Then answer three questions for every table. Whose row is this? Who can read it? Who can change or delete it?

Everyone can see which machines are busy. Only the person who started a machine can end it early. Write this into your prompt. If you use Supabase, these rules are called Row Level Security. Turn it on for every table and ask the agent to write the rules. Without them, anyone who finds your project's public key can read and change every row.

UI/UX prerequisite

UI is what the screen looks like. UX is how it feels to use it. Before the agent draws anything, draw your screens on paper. Put the main action where a thumb can reach it. Name the button by what it does. Start is unclear, Use this machine is clear.

Fill the screens with real content. A long name, a floor with no machines, a moment when every machine is full. What does the screen say then? An empty screen with nothing on it looks broken.

Open it on your phone, because people will use it standing in the laundry room with a basket in their hands. Make the text bigger in the phone settings and look again. Choose the colours and fonts yourself instead of leaving them to whatever the agent picks.

Security prerequisite

Being logged in and being allowed are two different things. After login, the app knows who you are. It still has to check, on the server, whether you are allowed to end this machine's usage. Hiding a button is not a check.

API keys are passwords for services, like the key that lets your app use an AI model and charges you for it. A key inside the frontend code can be read by anyone who opens the page's code. Keep secret keys on the server, in environment variables, and never commit them to GitHub.

Git prerequisite

Git keeps the versions of your project. Every time something works, commit it. When the agent breaks something on the next prompt, and it will, you can go back to the version that worked. Push it to GitHub so it does not live only on your laptop.

Deploy prerequisite

Localhost is your own computer, so the link works only for you. To give the app to your dorm, deploy it to a host like Vercel or Netlify. Your secret keys go into the host's environment variables, not into the code. After deploying, open the address on a friend's phone and try the main action once.

Build it

Now build in small steps. First the tables, then one whole feature. A person opens the app, sees the machines, starts using one, and everyone else sees it as busy. Make that work all the way before you add anything else. Check it yourself, commit it, then ask for the next thing.

And tadaa! Your project is ready.

I hope that you are not one of the people who think they are Elon Musk with one wrapper. Also, don't let arrogance get to you, and always stay open to learning.