What I will not teach you yet, and why
I will not teach a beginner to add logins, store private data, take payments or build a password system by asking an AI for one. Those features are possible, but their failures are hard to see and can harm somebody other than you. "Not yet" is a safety boundary, not a verdict on what you can eventually build.
A quick check, before we start
Adding a login is just another feature, like adding a new section or changing a colour.
Reveal the answer
False.
A colour can be wrong in public and you can see it. A login can look perfect while allowing one person to see another person’s information. The interface may be small; the responsibility behind it is not.
What will you not teach me yet?
In this first course, I will not teach you to build or launch anything that:
- Creates user accounts or handles passwords
- Decides which user may see or change which information
- Stores personal, confidential, health or financial data
- Takes payments directly
- Sends consequential automated decisions or messages
- Depends on a custom database you cannot inspect, back up and restore
- Could materially harm somebody if it is wrong, unavailable or exposed
I will also not teach you to paste passwords, private records, customer lists or secret keys into an AI conversation. A model is not a private notebook simply because the conversation feels one-to-one.
This is not because these features are impossible with AI. They are remarkably easy to produce. That is exactly why the boundary matters.
Why draw the line here?
Up to now, most mistakes in your project have been visible and reversible. A heading is too large. A link goes to the wrong place. A mobile menu jumps. You can see the problem, return to a known working version and try again.
Logins, permissions, databases and payments introduce failures that may be invisible to the person testing the site:
- A user can read another user’s record by changing an address.
- A reset link remains valid after it should have expired.
- A secret key is accidentally published with the site.
- A database backup exists but cannot be restored.
- A form stores more personal data than anyone realised.
- A payment succeeds twice after a visitor presses back.
- An account is deleted from the screen but remains in other systems.
The page can look flawless while all of that is true.
This is where “I tried it and it worked” stops being an adequate test. Security is not a visual finish applied at the end. It is a property of the whole system: who can do what, with which data, under which conditions, what happens when something fails, and how you would know.
But can’t I just ask the AI to use a trusted service?
Using an established authentication, database or payment provider is usually safer than inventing those systems yourself. It does not remove your responsibility.
Someone still has to configure permissions, protect keys, understand what data is collected, set retention rules, handle deletion requests, test recovery, watch for misuse, apply updates and respond when something goes wrong. A trusted component can be placed into an unsafe design.
The model can help with all of those tasks. It cannot accept the consequences on your behalf, and its confidence is not a security review.
What can I build instead?
Almost the whole useful web remains open to you.
You can build pages, portfolios, explainers, event sites, resource libraries, calculators that keep information on the visitor’s device, prototypes using obviously fictional data, and forms handled by a reputable service with the minimum information required.
If your idea eventually needs an account, build the public and non-sensitive parts first. Show the journey using fake users and fake data. Learn whether the idea is useful before collecting anything real. Link out to an established booking or payment service rather than recreating it inside your first project.
A safe prototype is not a lesser version of the idea. It is the version that lets you learn without making strangers carry your learning risk.
When does “not yet” become “now”?
Not after a certain number of prompts. You are ready to go further when the project has a stronger process around it.
Before adding sensitive features, you should be able to:
- Explain what data the service needs and why
- Name who may read, change, export and delete each kind of data
- Keep secrets out of the code and out of prompts
- Work from a repository with version history
- Test changes before they reach the live service
- Restore from a backup, not merely create one
- Use separate test and live environments
- Keep dependencies updated
- Record failures and respond to them
- Ask a suitably experienced person to review the design and the implementation
- Meet the privacy, consumer and sector rules that apply to the real use
That later project may still be vibe coded. The difference is that it is no longer being verified by vibes.
Why put this lesson in “Can I trust it?”
Because trust includes knowing where your competence ends.
A responsible course should not only show you what a tool can do. It should tell you when the consequence of being wrong has outgrown the checks you currently know how to run. The boundary protects the people whose passwords, money and information would otherwise become your practice material.
There is no shame in bringing in a developer, security specialist, privacy professional or lawyer. Vibe coding gives you a far better way to explain the problem, prototype the experience and participate in the build. It does not require you to pretend that one person and one model now contain every profession the project needs.
Where can I see the boundary in this course?
The lesson on the best first project deliberately recommends a page with no accounts, payments or private data. The lesson on AI-generated code quality teaches checks a beginner can run from the outside. This session marks the point where outside inspection is no longer enough and deeper technical assurance has to enter the room.
So, what will you not teach me yet, and why?
I will not be making courses for anything that does not exist on drkishanrees.com.