Who should be able to use your app? Should people need to log in? How do you control what different users can do?
This guide helps you describe your login and access control needs to Adaptive—whether you're building something open to everyone, something private, or anything in between.
The first thing to understand is what type of app you're building. Everything else flows from this:
Open Apps
No login needed—anyone can use them freely
Examples: Calculator, weather app, informational site, marketing page
Partially Protected Apps
Some features are open to everyone, others require login
Examples: Blog where anyone can read but only logged-in users can comment; marketplace where browsing is open but purchasing requires login
Fully Protected Apps
Login required for all access
Examples: To-do list, order manager, member portal, internal tools
Adaptive automatically figures out which type your app needs based on what you're building. If you want to change it, just say what you need—for example, "I want users to log in before they can access the app" or "Let anyone browse, but require login to purchase."
If your app is Partially Protected or Fully Protected, users will need to log in. Here's how Adaptive handles it:
The Login Experience
Handled automatically by Adaptive
Access Control
You describe, Adaptive builds
Think of it this way: Adaptive handles the "log in with email" part automatically. You just describe who should have access and what they should be able to do.
When building Partially Protected or Fully Protected apps, here's what's fixed and what you control:
Adaptive Handles This
These parts of the login experience are standard and can't be changed:
Why? Just like Stripe handles payments and Shopify handles checkout, Adaptive handles the login system. You get security, reliability, and users staying logged in—without building any of it yourself.
Tell Adaptive What You Need
After someone logs in, you control everything about how your app works:
Pick the scenario that matches your needs:
→ Open App
Examples: Calculator, weather widget, blog, landing page, public documentation
Globally accessible URL. No login screen ever shown.
All data is either local (client-side) or shared public data. No user-specific storage.
Instant access. Zero friction for your users.
→ Partially Protected App
Examples: Blog with comments, marketplace, recipe site where you save favorites
Public read access. Protected write access.
Public content is visible to all. User-specific data (favorites) is linked to the account.
Users can browse anonymously. Clicking "Save" triggers the login modal. Context is preserved after login.
→ Fully Protected App
Examples: Todo list, expense tracker, personal journal
Login required immediately upon visiting the site.
Strict isolation. All database queries automatically filter by the logged-in user's ID.
Users see a branded login screen first. Post-login, they enter their private workspace.
→ Fully Protected App
Examples: Team workspace, client portal, beta product
Restricted to a whitelist of email addresses.
New sign-ups are checked against the invite list. Uninvited users are blocked during registration.
You get an admin interface to add/remove allowed emails.
→ Fully Protected App
Examples: Content management system, order dashboard with managers and staff
Users are assigned roles (ADMIN, EDITOR, VIEWER).
API endpoints and UI elements check the user's role before allowing actions.
Backend validation ensures users cannot perform actions outside their role's scope.
→ Multiple Apps
Examples: Internal staff app + external client portal that share data
Two distinct frontends sharing a backend/database.
Single Sign-On (SSO) experience. Users have one account but different permissions per app.
Client app creates records; Staff app views/processes them. Contexts are kept separate.
→ Fully Protected App
Examples: Social app, community forum, any app where users have public identities
Login → Onboarding (Profile Creation) → App Access.
A public Profile record is created and linked to the private User auth record.
Auth details (email/phone) remain private; Profile details (username/avatar) are public.
Yes! Authentication is completely optional. Your app can be:
Just tell Adaptive which type you need or which parts require login. See "Three Types of Apps" above for details.
Username/password login is not supported. The platform uses email/phone verification for security. However, you can achieve a similar experience with a different approach:
You get secure login + your custom user experience. See "Custom User Profiles" in the scenarios above for details.
Key concept: The same person has separate user records in different apps, but the platform knows they're the same person.
How it works:
Why this matters:
Example: You build a staff app and a client portal. When Sarah logs into both:
Yes! Adaptive can build access restrictions for you. You can request:
See "Invite-Only Access" and "Role-Based Access" in the scenarios above for examples.
Adaptive can build complex permission systems for you. You can request:
Just tell Adaptive what you need in plain language. After users log in, Adaptive builds whatever permission logic your app requires.
Yes! The platform uses industry-standard security practices:
Just like Stripe handles payment security, Adaptive handles login security—so you don't have to.
Now that you understand the three types of apps and how login works, here's how to build what you need:
Think about who should be able to use your app:
Adaptive will figure this out automatically, but you can explicitly tell it what you need.
Use plain language to describe who should have access and what they can do:
Personal dashboard:
"Each user sees only their own data"
Invite-only:
"Only people I invite should have access"
Role-based:
"Admins can edit everything, regular users can only view"
Adaptive handles the login system automatically and builds the access control you described:
Remember: Start with which type of app you're building, then describe who can access it and what they can do.