QRSETU Dev Portal

Appearance

Foundational Screen Prompts ​

Grounded, drift-free briefs for the core foundation of QRSETU. Each brief reflects the actual current implementation in the codebase plus the intended behavior, so the design team can create production-ready screens that engineering can build as-is. Read the Screen Coverage Mandate first, and apply the global rules from the PDPR Design Prompt to every screen below.

Applies to every brief on this page

Design each screen for both platforms (native mobile via Expo, and the installed-app desktop experience). Consume tokens only, never hardcoded colors. The current code hardcodes brand values (golden #FFE591, coral #FF6A3C or #FF6A3C, navy #213A57, and many gray shades). In the design system these become tokens: golden saffron primary, coral secondary, navy ink. Keep the 3XL rounded signature (the code already uses large rounded shells and softer inner panels). Design all states: empty, loading, success, error, permission, edge cases. Do not use em dashes.

Screen inventory (foundation) ​

ScreenRouteStatusReads / writes
Landing page/ImplementedStatic, plus client-side QR generation
Sign up/signupImplemented (Google disabled)Supabase Auth signUp
Login/loginImplemented (Google disabled)Supabase Auth signIn, password reset
Password reset requestmodal on loginImplementedSupabase Auth reset email
Update password/update-passwordPlanned or partial (redirect target exists)Supabase Auth update
Admin login/admin/loginImplementedAuth + profiles.role check
Onboarding/onboardingImplemented (business-first)validate-user-input EF, manage-profile EF
Default dashboard/dashboard/homeImplemented (menu-centric)useDashboardData
Profile/dashboard/profileImplementedmanage-profile EF, validate-user-input EF
Settings/dashboard/settingsImplementedmanage-settings EF, manage-account EF
Authenticated app shellwraps /dashboard/*ImplementedNavigation, guards

Status reflects the codebase today. "Planned" items still need requirements before design.

1. Landing page ​

Route: /. Public marketing page. Also the entry point that routes signed-in users to /dashboard/home.

Sections (in order): header with navigation, hero, live QR generator, features, pricing, testimonials, blog highlights, FAQ, footer, and a floating WhatsApp action.

QR generator (interactive, client-side): the hero generator supports these QR types, which must all be represented: URL, Contact, Email, SMS, WiFi, Location, Event, Payment, Social Media, Menu, Business Card, Coupon, App Download, Video, Document. Include a type picker, a form that adapts to the chosen type, a live preview, and download and share actions.

Features section: Instant Generation, Advanced Analytics, Secure and Reliable.

Primary calls to action: Sign up, and Login for existing users. Pricing should reflect the freemium model (free tier with ads, paid tiers remove ads and unlock advanced features), but do not invent specific prices unless documented.

States: default, QR generated, QR generation error or invalid input, and a loading state for the preview. Design the header for both a wide desktop layout and a native or compact mobile layout.

Notes: this is a marketing surface, so it may read more like a premium product site than the installed-app shell, but it must still use tokens and the brand language. Signed-in visitors are redirected away from this page.

2. Sign up ​

Route: /signup. Two-column card on a neutral background: form on one side, a rotating image carousel on the other (four lifestyle images, auto-advancing, with indicator dots).

Copy: title "Create an Account", subtitle "Start your journey with QR Setu".

Fields and actions:

  • Continue with Google button. It is present but currently disabled. Design both an enabled and a disabled state, and treat Google sign in as planned, not active.
  • Email (required).
  • Password (required, minimum 6 characters, shown with a hint).
  • Create Account button (loading label "Creating account...").
  • Link to Login for existing users.

Behavior: on success, show a confirmation message "Check your email for the confirmation link" and route to Login to wait for email confirmation.

States: default, submitting, field validation error, auth error (toast), and the email confirmation success message. Design the mobile layout as a single column with the carousel above or hidden.

3. Login and password reset ​

Route: /login. Same two-column card and carousel pattern as sign up.

Copy: title "Welcome Back", subtitle "Login to continue to QR Setu".

Fields and actions:

  • Continue with Google button, currently disabled (design enabled and disabled states, treat as planned).
  • Email (required).
  • Password (required), with a "Forgot Password?" trigger beside the label.
  • Login button (loading label "Logging in...").
  • Link to Sign up.

Behavior: on success, all users (including admins) route to /dashboard/home. The admin panel is reached only through the dedicated admin login.

Forgot password (modal): title "Reset Password", one Email field, and a "Send Reset Link" action (loading label "Sending..."). On submit it sends a reset email. Design the modal and its sending and sent states.

Update password screen (/update-password): this is the reset-link target. Requirements are not yet documented, so produce a brief and flag it: it should take a new password and a confirm password, validate them, submit the update, and show success then route to login. Mark as an open question until confirmed.

States: default, submitting, invalid credentials error (toast), and the redirect transition (do not flash the form after success).

4. Admin login ​

Route: /admin/login. Dedicated, noindex administrator entry. Two-column card: form on one side, a branded panel on the other with a QR icon, "QR Setu", "Admin Portal", and a short line about secure administrative access.

Copy: title "Admin Portal", subtitle "Secure access for system administrators only".

Fields and actions: Email, Password with a "Forgot Password?" trigger (admin reset modal titled "Reset Admin Password"), a "Login to Admin Portal" button, and a link "Not an administrator? Go to User Login".

Behavior and states: authenticate, then verify the account has an admin or super admin role. If the account is valid but not an admin, sign out and show an inline "Access Denied" alert. Design the inline error alert state ("Authentication Failed" with a message), the submitting state, and the success transition to the admin area. This screen must feel secure and restrained.

5. Onboarding ​

Route: /onboarding. A five-step wizard in a large rounded card centered on a warm gradient background. Shows a segmented progress bar with check markers and a "Step X of 5" label. Each step animates in horizontally. Business-first today (see the note at the end).

Steps:

  1. About you. Heading "Welcome! Let's get started", subtitle "What should we call you?". Fields: Full Name (letters and spaces, minimum 2), and Mobile Number with a country-code selector (options include +91, +1, +44, +49) and a 10 digit number.
  2. Brand. Heading "Tell us about your brand". Field: Brand Name (letters, numbers, spaces, minimum 2).
  3. Industry. Heading "What's your industry?", subtitle "We'll tailor features to your business type". Field: Business Domain, a searchable dropdown loaded from the business domains list, each option showing a name and a short description, with a search box and an empty "No domains found" state.
  4. Location. Heading "Where are you based?". Field: Country selector, defaulting to the default country.
  5. Unique URL. Heading "Choose your unique URL", subtitle "This will be your profile's web address". Field: Slug (lowercase letters, numbers, hyphens, 3 to 30 characters). It runs a live availability check (debounced) and shows checking, available, and unavailable states, a clear affordance, and a preview line "Your website will be available at: qrsetu.com/your-slug".

Navigation: Previous and Next buttons, and on the final step a "Complete Setup" button (loading label "Setting up..."), enabled only when the whole form is valid.

Completion: on submit, save the profile and mark onboarding complete, then show a celebration screen. Design the celebration and its error fallback.

States per step: default, inline validation error (with an alert icon and message), the slug checking, available, and unavailable states, the submitting state, and the celebration state.

Important planned variant (open question, must be designed): onboarding is business-first today (brand, industry, and slug are required). QRSETU also serves individuals with no business. Design a personal or skip-business path so an individual can complete a minimal onboarding (for example name only) and reach a generic dashboard without a business profile. Flag the exact minimal fields as an open requirement.

6. Default dashboard ​

Route: /dashboard/home. The landing screen after login. Data comes from a dashboard data hook (bio pages, QR codes, stats, digital menu stats, whether digital menu is enabled, business domain id, and subscription data).

Current implemented content:

  • Welcome hero at the top, aware of the user's business domain.
  • Digital Menu section (conditional on the digital menu being enabled): a heading "Digital Menu" and a grid of six stat cards, each with an icon, a value, a label, and an action: Active digital menus (Create New), Menu Categories (Manage), Dishes and drinks (View All), Hidden Menu Categories (View), Hidden Dishes and Drinks (View), Today's Special (View).
  • Below the stats, two placeholder panels: "Recent Orders" (empty state "No recent orders found", "Real-time order tracking coming soon") and "Top Performing Items" (empty state "Data insufficient", "Add items to see what's popular").
  • No active plan modal: for a free user on the relevant domain with no active plan, a blocking modal titled "No Active Plan" that invites the user to contact support, showing WhatsApp and Email contact rows and a response-time note. Design this modal and its dismissable and blocking behavior.

Planned content (currently present in code but disabled, design as future states): a top stats row (BioLinks, Service Cards, Total Scans), primary action cards (Create Website, Create Service Card), and recent activity lists (Recent BioLinks, Recent Service Cards). Design these so they can be turned on without a redesign.

States: loading (skeletons for the stat cards and lists), the digital-menu-enabled layout, a first-run or zero-data layout for a brand new user, and the no-active-plan blocking modal. Because the dashboard adapts by what the user has enabled and by plan, define these variants explicitly.

Generic-audience note: design a dashboard variant for an individual with no business (generic mode), surfacing generic tools (QR generator, BioLink, digital card, forms, reminders) rather than business stats. Flag the exact composition as an open requirement.

7. Profile ​

Route: /dashboard/profile. A header card plus a four-tab form. Writes go through the profile edge function, with input validation.

Header card: avatar with upload, the brand name (or "Your Brand"), a subscription tier badge, the email, and an "Active" status badge.

Tabs:

  1. Basic Information. Owner Name (required, up to 30 characters) and Mobile Number (up to 10 digits). Save Changes button with validating and saving states.
  2. Business Details. Brand Name, Business Industry, City, State, Pin Code, and GSTIN. These are currently read-only in this tab. Design a read-only presentation and, as a planned state, an editable version, and flag which fields become editable as an open question.
  3. Business Hours. A seven-day hours editor (per-day open and closed times), with a loading skeleton for seven rows.
  4. Social Media. Links for Instagram, Facebook, Twitter, LinkedIn, YouTube, and WhatsApp.

States: loading (a full profile skeleton), per-section loading (lazy sections with skeletons), validating, saving, per-field validation errors, a section error boundary state ("Something went wrong, unable to load this section"), and saved success feedback.

Generic-audience note: for an individual with no business, the Business Details and Business Hours tabs may be hidden or replaced with personal fields. Flag as an open requirement.

8. Settings ​

Route: /dashboard/settings. Title "Settings", subtitle about preferences, account security, and billing. Three tabs.

Tabs:

  1. General. Account preferences, including default currency and advertising preference (these are the settings the general settings service manages). Design each preference control with its saving state and confirmation.
  2. Security. Two groups. Change Email: Current Email, New Email Address. Change Password: Current Password, New Password, Confirm New Password. Design validation, submitting, success, and error states for each.
  3. Danger Zone. Delete Account, with a clear, explicit confirmation flow (Cancel and Delete Account actions) that states the consequences plainly. This maps to the account and data deletion requirement, so treat it as a careful, non-accidental destructive flow.

States: loading (settings skeleton), saving a preference, a section error boundary state ("Section Unavailable, we couldn't load this settings section"), and the destructive confirmation and its progress and result.

Note: account and data deletion must follow the privacy guidance in the PDPR. Make public versus private and destructive consequences unmistakable.

9. Authenticated app shell and navigation ​

Wraps: all /dashboard/* routes. This is not a single screen but the frame every dashboard screen sits inside, so it must be designed for both platforms.

Desktop: a persistent app shell with a refined sidebar for primary areas, a quiet top bar for context and account, and a spacious content area. Include a command surface for power users if approved.

Mobile: native navigation, a bottom tab bar for primary areas, and native stack transitions for depth. Contextual actions use bottom sheets.

Requirements to confirm (open): the exact set of primary navigation destinations (for example Home, Digital Menu, BioLink, Website, QR, Profile, Settings) differs by what the user has enabled and by audience (business versus generic). Flag the final navigation model as an open requirement and design it to adapt without a redesign.

Open questions to resolve before or during design ​

These are the gaps found while grounding these briefs. Each must be answered rather than assumed:

  1. The minimal personal or skip-business onboarding path and its exact fields.
  2. The generic-mode dashboard composition for individuals.
  3. Which Business Details fields become editable in Profile, and when.
  4. The update password screen requirements.
  5. The final primary navigation model for the app shell across business and generic modes.
  6. Confirmed pricing for the landing pricing section.

Log confirmed answers back into these briefs, then design. Do not fill these gaps with generic assumptions.