Why 'a Signup in Five Minutes' Is a Trap
Start with a piece of news that sounds like someone else's problem. Last month Korea's data protection commission fined Coupang 624.6 billion won — the largest privacy penalty on record. The names and emails of 33.7 million members leaked, and the entry point was, of all things, the 'edit my info' page. Yet the verdict wasn't a sophisticated hack; it was 'a failure of basic safety management.'
Why start here? Because these days you can type one line to an AI — 'make signup and login work with email and password' — and a screen appears in five minutes. Anyone who has built a service has probably started this way. The problem is that a screen appearing does not mean signup is finished.
A quick bit of groundwork. Login is technically two jobs. One is authentication — confirming 'who are you.' The other is the session — remembering 'I've confirmed you, so I won't ask again for a while.' And a password must never be stored as-is by the service. It's converted into an irreversible form for storage, and that conversion is called a hash. A properly built service means even the operator doesn't know users' passwords. Even if a hacker steals the whole database, the original passwords can't be recovered.
Fortunately, web frameworks like Ruby on Rails handle this hashing automatically. Even if you never say 'use a hash,' the AI uses the framework's built-in mechanism to store it encrypted. So up to here it's basic hygiene the tool takes care of. The real problem begins next — in the territory where a human has to decide what to ask for.
Missing (1)(2) — Password Reset and Member Info Editing
The first thing missing is password reset. Will users forget their password? Not a matter of probability — they certainly will. Yet the screen built from a one-line prompt has no 'Forgot your password?' A user who forgets can't get back in and ends up emailing support. A large share of the first inquiries after launch are password problems, and once you start changing them by hand one person at a time, you're running not a service but a call center.
There's something to decide here. You'll send a reset link by email — how many minutes should it stay valid? Should it become void after one use? If the link stays alive forever, the moment someone's mailbox is breached their account is breached too. Deciding this is policy, not code.
The second is member info editing. I want to change my email; I want to change my password — natural requests, yet the one-line output has no way to do them. Here too there's a decision: when changing a password, do you ask for the current password once more? If not, someone who briefly leaves their seat at a cafe can have their whole account taken. Recall that the Coupang leak happened at exactly this 'edit my info' page, and you see how heavy this decision is.
Missing (3) — Account Deletion, a Decision the Law Hangs On
The third is the most important: account deletion. Services launched with no deletion feature are more common than you'd think. But a user who wants to leave will certainly appear, and with no way to do so, they email you — angry. And this doesn't end as an emotional matter. Under the personal information protection law, users have the right to delete their own data. Stall on a deletion request and it becomes a legal problem.
The decision in deletion is this: do you truly erase the data, or only mark it as if erased? Marking it only is called a soft delete. Which is right depends on the nature of the service. A service with payment history has a legal duty under tax law to retain transaction records for a set period, so erasing everything actually creates a problem.
So the usual answer is a compromise. Anonymize personally identifying information like email (erase or replace it so no one can tell who it was), while keeping the transaction records themselves. You also have to decide that 'a deleted account can no longer log in.' This judgment is policy, not code, and deciding it before building is what lets you instruct the AI precisely.
Missing (4)(5) — Privacy Policy and Terms, and the Copy-Paste Trap
The fourth and fifth aren't features but documents. Yet these two pages are matters of law and contract. First, the privacy policy. The moment you receive a single email you become what the law calls a 'personal information handler.' You take on a duty to define and disclose what information you collect and why, how long you keep it, and how you destroy it. Failing to create or disclose one alone is grounds for a fine of up to 10 million won under the law.
Terms of service are different in nature. This is a matter not with the government but with the user. Terms are the contract a user forms with the service the moment they sign up. Without this contract, when a user hurls abuse at another or commits fraud and you say 'your account is suspended,' you have no answer to 'on what grounds?' In a service where people gather, terms are the document that protects the operator.
Here's a common thought: 'Can't I just copy those documents from somewhere?' Everyone does, in fact. But there's a trap. If the privacy policy differs from the actual service, that itself is a violation. Writing that you collect information you don't, or collecting something and not writing it, is wearing clothes that don't fit. So this document has to start not from copying but from 'what data does my service handle?' And who knows that data structure best? The AI that just wrote the code.
The Admin Page and the Illusion That 'Social Login Ends It'
The moment member data exists, one more thing becomes necessary: someone to look into and manage it — an operator's admin page. A screen to search the member list, see who's joined or left, and suspend members who cause problems. A decision hides here too. How much of a member's information should an admin be able to see? Passwords are hashed, so even the operator can't see them. Email may need to be visible for handling inquiries. Setting the scope an admin can see is itself a policy decision, bound by the principle of 'minimum access to personal data.'
And the suspend button. The grounds on which an admin can suspend a member lie precisely in the terms of service. Build a suspend button without terms and it's a feature for throwing people out at the operator's whim; with terms, it's a legitimate measure under a contract. Document and feature connect like this.
Finally, a common misconception: 'If I add Kakao or Google social login, doesn't this homework disappear?' Since you no longer take a password, password reset does shrink by one. But account deletion, the privacy policy, and terms are all still needed. In fact the privacy policy needs an added item: 'what information we receive from Kakao.' Social login only removes one of the five; it doesn't erase the whole homework.
The Real-World Prompt — Make the AI Ask You First
So how should you actually instruct it? On the left is the one line everyone types; on the right is a prompt at the level a real service needs. The length differs quite a bit, but look closely and there's no hard technical jargon. It's all the policy decisions we discussed above: reset link 30 minutes, deletion marked-only and anonymized, privacy policy based on actually collected fields. Not coding knowledge, but decisions about how to run a service.
The key is the single line at the very end of the prompt: 'Before you implement, if there's any policy I haven't decided that needs deciding, ask me first.' Add this line and the AI doesn't start coding — it asks back. 'Should I require email verification, or let them sign up right away?' 'When changing an email, is verification of the new email needed?' Being asked these is itself a lesson, because the AI pulls out, as a list, the decisions you hadn't thought of.
This one line turns the AI from a mere coder into a planning partner. Policy accumulates as you answer, and by watching what the AI asks you learn what you didn't know. I recommend always putting this sentence in your real-world prompts.
Make it so I can sign up and log in with email and password.
Also make a home screen that shows a welcome message after login.Implement signup and login.
- Sign up with email and password (8+ characters).
- Send the password reset link to the registered email, valid for 30 minutes only, void after one use.
- Member info editing: let a logged-in user change email/password. Ask for the current password once more when changing.
- Account deletion: doable from the my-info page. To prevent mistakes, ask for the password before proceeding. Don't truly delete the data — mark it as withdrawn, then anonymize personally identifying info like email. A deleted account can't log in.
- Create a privacy policy and terms-of-service page, written against the information this service actually collects. Put links in the footer of every page.
- At signup, add checkboxes to agree to the terms/privacy policy, and require agreement to sign up.
Before you implement, if there's any policy I haven't decided that needs deciding, ask me first.Conclusion — Skill Comes from the Decision List
To sum up: building a signup with AI takes five minutes. But for it to become a 'service,' a decision list has to stand first — password reset, member info editing, account deletion, privacy policy, terms of service, and an admin page. The AI writes the code, but the human has to make the decisions.
This much for one signup — and building a whole service piles up dozens of such decision lists. Every time a feature changes, the database structure changes too, and the mechanism that safely manages that change history is called a migration. Changes are recorded in order and can be rolled back if something goes wrong, so you can safely fix the database even after launch. And each time a feature changes like that, the privacy policy and terms have to keep being updated — where, again, you can lean on the AI that knows the code.
So in the AI era, a builder's skill comes not from code but from this decision list. The AI writes all the code. But what to decide is known only by those who have built and run a service. Is your service's decision list ready?