DandyLine — Sign-In & Account Creation

01

Why this screen matters

▶

The Sign-In screen is a 30-second commitment moment. The Gardener has just been introduced to DandyLine; now they're being asked to create an account. This is where most apps lose people. The friction has to be invisible, the trust has to be obvious, and the path forward has to feel like an obvious next step rather than a chore.

Three things this screen does

Lowers friction — SSO buttons (Google, Apple) eliminate password-creation as the primary path.
Preserves the email path — for Gardeners who don't want SSO, traditional email sign-up is still available.
Reinforces trust — small, quiet privacy signal (one line), not a wall of legal text.

What it does NOT do

Ask for a phone number (deferred to setup screen 4 if SMS notifications are opted into)
Ask for a name (handled in onboarding setup if needed; SSO often provides it)
Show feature lists, screenshots, or marketing copy (the intro flow already did its job)
Pop a CAPTCHA or human-verification gate (per safety rules — automated CAPTCHAs are user-completed only)

Brief locked · 2026-05-02

02

The screen — mockup & copy

▶

✿

Plant your first Seed.

A few seconds, and you're in.

or

[email protected]

Already have an account? Sign in

By continuing, you agree to our Terms and Privacy Policy.

Headline (drafted)

Plant your first Seed.

Sub (drafted)

A few seconds, and you're in.

Why this copy

The headline echoes the final slide of the Onboarding Intro — the Gardener has already been told this is what they're about to do, so the sign-in screen reinforces rather than re-introduces. The sub addresses the only real anxiety at this moment: how long is this going to take?

Button order

Google first — broadest reach, especially on Android and desktop
Apple second — required for iOS App Store later; familiar privacy-leaning option
Email last — visually de-emphasized below an "or" divider, but always available

Mode toggle

Single screen serves both new sign-up and returning sign-in. The "Already have an account? Sign in" link toggles the screen mode (changes button labels from "Continue with X" to "Sign in with X"; reveals a password field for the email path). Cleaner than two separate screens.

Legal fine-print

Single line at bottom: "By continuing, you agree to our Terms and Privacy Policy." Tap-through links open the policies. Compact. Honest. Nothing buried.

Brand voice on this screen: calm, fast, trust-signaling. NO “Sign up now to unlock!” energy. NO countdown timers. NO “Join 10,000+ Gardeners.” (We don't have 10,000 Gardeners. Honesty over inflation.)

03

The SSO ask for Josh

▶

SSO is the most strategic decision for this screen. Per dandyline-app/CLAUDE.md, Google and Apple OAuth are stubbed but not built (planned via Arctic library). Building SSO into the closed-beta MVP would meaningfully reduce friction at the most fragile moment of onboarding — but it's non-trivial work that may compete with other build priorities.

What we're asking Josh

Is SSO (Google + Apple) reasonable to wire up before closed-beta launch, or should we ship email-only first and add SSO post-beta?
If yes — what's the rough lift estimate, and which scaffolding (callback URLs, identity provider config, secret management) needs to be set up on Ashley's side?
If later — what's the smallest acceptable email-only flow that doesn't tank conversion? Magic-link instead of password? Standard email + password?

Why it matters more than it sounds

On the closed-beta cohort (10–20 hand-picked adults), SSO matters less — those Gardeners will sign up regardless of friction. But SSO presence shapes investor demos and the "would you sign up for this?" reaction during user testing. A first-time user clicking through 5 password-creation fields lands a different impression than one tapping “Continue with Google.”

Action — added to Pinned items in QUESTIONS-FROM-ASHLEY.md

This question is being added to the app repo as Pinned item 8 (Section N) so Josh sees it on next pull. The full draft language lives in the homework / Josh-doc edits batched with this concept doc.

Backstop plan

If Josh says SSO is too heavy for MVP: ship the email-only screen with password-reset already wired (which is built). The screen mockup degrades cleanly — remove the SSO buttons, the "or" divider, and lead with the email input. Email-only is honest, fast, and not a deal-breaker.

04

Behavior details

▶

SSO success path

Google or Apple completes the OAuth handshake → DandyLine creates the account using the SSO-provided email and (if available) display name → Gardener is routed to the Onboarding Setup flow (ux-onboarding-permissions.html) automatically. No intermediate "account created" screen — the canonical animated dandelion appears on the bridge slide of the Setup flow, doubling as both confirmation and a quiet loading beat.

Email new-account path

Email entered → email validated for format → "Set a password" field appears → password set → standard email verification flow (Resend integration per Josh's stack) → on verification, Gardener routes to Onboarding Setup.

Email sign-in path

Email entered → password field appears (or magic-link option if we go that route) → on submit, routes directly to the Field (skipping Onboarding Setup, since they've already been through it).

Password reset

Already built per dandyline-app/CLAUDE.md. The "Forgot?" link appears next to the password field on the email sign-in path, routes to the existing password-reset flow.

Error states

Email already in use during sign-up — gentle: "Looks like you already have an account. Sign in instead?" — not "Email already exists."
Wrong password during sign-in — "That password doesn't match. Try again, or reset it." — never reveal whether the email exists in our system (security + dignity).
SSO failure — "Google didn't respond. Try again, or use email." — concrete, no jargon.
Network failure — "Something on our end. Try again in a moment." — DandyLine takes the blame, not the Gardener's connection.

Account recovery options

Per Section H7 of QUESTIONS-FROM-ASHLEY.md (locked April 21): at signup, Gardeners are offered backup-method choice (backup email, recovery codes, phone, Guardian). Lives just past sign-up — on the Setup flow OR right after first password creation. Defer placement decision to build session.

05

Surfaces Affected

▶

ux-onboarding-intro.html — the predecessor flow. Slide 5's "Begin" CTA routes here.
ux-onboarding-permissions.html — the successor flow. Successful sign-up routes here.
App build (Josh) — packages/api/src/routes/auth.ts. Email/password routes are built; SSO is stubbed.
App build (Josh) — Arctic OAuth library integration for Google + Apple, per docs/platform/decisions.md.
QUESTIONS-FROM-ASHLEY.md — Pinned item 8 / Section N added with the SSO ask.
Account recovery setup screen — exists post-sign-up, not on this screen. Per H7 lock April 21.
Privacy Policy + ToS pages — linked from the legal fine-print at the bottom of this screen. Drafts are Row #10 of the build roadmap.

06

Open Questions

▶

① SSO Wiring Decision

Pending Josh's response on whether Google + Apple OAuth ship in closed-beta MVP or wait until post-beta. Captured in Pinned item 8 of QUESTIONS-FROM-ASHLEY.md.

② Magic-link vs. Password

Email path — traditional email + password, or magic-link? Magic-link is lower friction but requires a different UX. Lean: traditional + password (matches what's already built). Confirm with Josh.

③ Single Screen vs. Mode Toggle

"Sign up" and "Sign in" on one screen — confirm this works, or split into two screens? Lean: one screen, mode-toggled by the small "Already have an account?" link. Common pattern, less bounce.

④ Apple Provides Display Name?

Apple's "Sign in with Apple" can be configured to share name + email or hide them (private relay). DandyLine should request name + email but accept whatever Apple provides. Edge case: if Apple hides email, do we have a fallback? Confirm with Josh.

⑤ Phone Number Capture Timing

If SMS-only at MVP, we need the phone number somewhere. Options: (a) here at sign-up as an optional field, (b) at Setup screen 4 (notifications), (c) defer until first opt-in to SMS. Lean: optional field on sign-up — collects it once, lets the Notifications screen treat it as already-known.

⑥ Returning-User Detection

Can we auto-detect that a returning Gardener is signing back in (cookie, recent device) and pre-toggle the screen to sign-in mode? Polish item, not blocker.

⑦ Anti-Bot Strategy

Closed-beta cohort is invite-only, so bot risk is low. At public launch we'll need anti-abuse on email sign-up. Defer the decision; flag here so it's not forgotten.

07

Brand voice guardrails

▶

Words used on this screen (on-brand)

Plant, Seed — only in the headline echo
Continue, Sign in — neutral action verbs
Email, Apple, Google — provider-honest names

Words explicitly NOT used on this screen

Register, Activate, Unlock — too transactional
Free trial, Start now, Join the community — marketing-speak
Welcome back! — too cheerful for a 30-second moment
Profile, User, Account on this screen — those words exist later in the Gardener Menu, not at first commitment

Tone test: If a Gardener felt rushed, sold-to, or quizzed, this screen failed. They should feel like the door swung open easily and the room beyond looks calm. The whole screen should read as a threshold, not a checkpoint.