Working once is the start of a release decision
A prototype can answer an important question while remaining unsuitable for customer dependence. The reading-list reference deliberately keeps everything in one browser. That is a useful learning boundary. It is not a promise of account recovery, shared access, or a durable cloud backup.
Write the promise you are making
For a public learning demo, the promise might be: “Try these interactions with fictional information; export anything you want to keep.” For a customer product, the promise might include saved work across devices, controlled access, support, and reliable recovery. The second promise requires additional engineering and operating decisions.
Use a release decision sheet
- Audience: who can access this version, and what may they rely on?
- Data: what is collected, where is it stored, how is it removed, and what happens after failure?
- Access: which actions must be enforced on the server for each user or role?
- Failure: how do users recognize an unsuccessful action and recover?
- Quality: which task, keyboard, screen-size, and regression checks were actually performed?
- Operations: who owns updates, errors, service costs, backups, and support?
- Rollback: how do you return to a known working version?
For each item, record evidence and remaining work. A checked box is not a certification. Get appropriate technical review when the product depends on sensitive records, payments, multi-user permissions, or integrations you cannot adequately evaluate yourself.
Adding login changes the product
A sign-in screen does not by itself protect records. A shared application needs server-enforced access rules, safe session handling, and an intentional account lifecycle. Test that one user cannot read or change another user’s records. Consider account recovery and deletion as real journeys, not later polish.
Build connected experiments in a test environment with fictional records first. Keep credentials out of browser code and the repository. Document which external services are required and what happens when one fails. A designer can contribute substantially to these decisions while working with an engineer on the controls.
Separate simulated actions from real ones
Label a fake checkout or sample booking clearly. Before enabling actual transactions or messages, verify the complete flow, error handling, permissions, and user confirmation. Do not let a button’s confident wording promise something the implementation cannot do.
Release the smallest version you can support
A shareable local prototype is already a worthwhile outcome. Publish it with its limitations, test the deployed URL, and keep the source checkpoint. If research indicates that people need shared records, make that the next scoped iteration rather than silently expanding the original promise.
Show the judgment in your portfolio
Explain why the first version stayed local, what you tested, and what evidence would justify a connected version. Label future capabilities as planned. Link to the demo and describe your role in design, implementation review, and testing. Honest boundaries make your work easier for another person to evaluate.
Complete the release and portfolio sections of your Project Passport. The goal is a useful artifact with a clear owner and clear limits, plus an informed next decision.