Lesson 5 / 126 min read

End-user accounts

Add real member signup and login so each person sees only their own data.

For personal trackers, member portals and saved favourites, your app can have its own user accounts. Just ask for it: "let users sign up and log in, and everyone sees only their own data".

Interactive example: the account flow

Signed in as:

devany.db · shared

· Closed on Mondays
· New season prices

Everyone sees this — even signed out.

devany.user · private

Switch between Ayşe and Mehmet: the shared list stays the same, the private list changes. That is exactly what devany.user gives you.

This is a simulation — no real email is sent and nothing is stored.

The member's journey

Email + password

Their own account

Private space

Only their records

Password reset

6-digit code by email

Member account vs staff role

Member account

Many people, each with their own account
Passwords are encrypted on the server
Everyone sees only their own data

Staff role

The same accounts — you grant the role from the dashboard
Opens the staff view inside the app
Verified on the server — nobody can promote themselves

Try it yourself

Try it yourself: an app with members

A small app with signup/login where data is per-person.

1Build a new app: "a personal habit tracker where users sign up and log in and everyone sees only their own records".
2Publish the app and enable email in the builder.
3Open the live link and sign up with your own email.
4Add a record, log out, log back in — is your record still there?
5Try the "forgot password" flow: the code should reach your inbox.

What you should end up with

You get an app with real members and see the difference between private and shared data first-hand.

Key takeaways

Just ask for accounts — signup, login and reset come built in.
A session lasts for the tab; a refresh means signing in again.
Code emails only work on a published, email-enabled app.