diff --git a/PROGRESS.md b/PROGRESS.md
index bacdd0c..94d8767 100644
--- a/PROGRESS.md
+++ b/PROGRESS.md
@@ -51,20 +51,59 @@ All 4 phases done. Tailwind utility clone deleted, all templates migrated to sem
 | 70 | Margin guard on sales (prevent discounts that breach minimum profit threshold) | 69 | 1h | planned |
 | 71 | Announcement bar (dismissable shop banner for active sales) | 69 | 1.5h | planned |
 
-### Onboarding UX improvements ([plan](docs/plans/onboarding-ux.md))
+### Onboarding UX v2 ([plan](docs/plans/onboarding-ux.md))
 
-| # | Task | Priority | Est | Status |
-|---|------|----------|-----|--------|
-| 1 | Redirect to dashboard after wizard completion with welcome flash | High | 30m | planned |
-| 2 | Add shipping setup to checklist, gate "Go live" on shipping existing | High | 1h | planned |
-| 3 | Add shop settings to checklist (name, currency) | High | 45m | planned |
-| 4 | Make checklist collapsible instead of dismissable | Medium | 15m | planned |
-| 5 | Add test order guidance (test card number, what to expect) | Medium | 45m | planned |
-| 6 | Skip completed wizard steps on revisit | Medium | 1h | planned |
-| 7 | Better provider connection error messages with help links | Medium | 30m | planned |
-| 8 | Add theme customisation tips to checklist | Low | 15m | planned |
-| 9 | Smarter "Sync products" checklist link | Low | 15m | planned |
-| 10 | Add email setup as optional checklist item | Low | 30m | planned |
+Based on usability testing (March 2026). Reworks the entire setup flow into a single guided journey with progress bar, forgiving validation, and contextual prompts.
+
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| A | Simplify initial setup to account creation only (email, password, shop name) | 1.5h | planned |
+| B | Guided setup flow with progress bar (multi-step, skippable, explains "why") | 4h | planned |
+| C | Forgiving API key validation (strip whitespace, format checks, helpful errors) | 1.5h | planned |
+| D | Email provider setup UX rework (recommended pick, grouping, guided flow, test email) | 2h | planned |
+| E | Contextual prompts for skipped steps (products, checkout, order detail) | 2h | planned |
+| F | Dashboard checklist and messaging rework | 2h | planned |
+| G | Coming soon page fixes (logo layout, admin login link) | 30m | planned |
+| H | External links UX (new tabs, icons, aria labels) | 1h | planned |
+| I | Input styling — WCAG AA/AAA compliance | 1h | planned |
+
+### Notification system overhaul ([plan](docs/plans/notification-overhaul.md))
+
+Replace floating toast/flash messages with inline feedback and persistent top banners. 110+ flash messages across 28 files to migrate.
+
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| 1 | Build inline feedback component | 1.5h | planned |
+| 2 | Build persistent top banner component (replaces flash) | 1.5h | planned |
+| 3 | Migrate admin forms to inline feedback (theme, pages, settings, email, providers) | 3h | planned |
+| 4 | Migrate remaining admin pages (media, products, activity, newsletter, redirects, nav) | 2h | planned |
+| 5 | Migrate shop pages (cart, contact, checkout, auth) | 2h | planned |
+| 6 | Migrate setup wizard notifications | 1h | planned |
+| 7 | Remove old flash/toast CSS and JS | 30m | planned |
+
+### Live site editor ([plan](docs/plans/live-site-editor.md))
+
+On-site editing overlay for admins: browse the real shop with a sidebar for theme and page editing. Inline contenteditable for text, live CSS variable injection for theme changes. Responsive layout (split view on desktop, overlay on mobile).
+
+| Phase | Description | Est | Status |
+|---|---|---|---|
+| 1 | Design: sketch approaches, pick one | 2h | planned |
+| 2 | Extract shared components from theme editor and page editor | 4h | planned |
+| 3 | Build editor wrapper LiveView with sidebar shell | 3h | planned |
+| 4 | Theme editing in sidebar (re-use theme controls, live CSS vars) | 3h | planned |
+| 5 | Block list and block settings in sidebar | 3h | planned |
+| 6 | Block selection: click-to-select with highlight on page | 2h | planned |
+| 7 | Inline text editing with contenteditable + phx-hook | 4h | planned |
+| 8 | Responsive layout (split view / overlay) | 2h | planned |
+| 9 | Save/discard/undo flow | 2h | planned |
+| 10 | Edit mode toggle (floating button for admins on shop pages) | 1h | planned |
+| 11 | Polish and testing | 4h | planned |
+
+### Quick fixes (from usability testing)
+
+| # | Task | Est | Status |
+|---|---|---|---|
+| 1 | Fix double radio button dots in theme editor | 30m | planned |
 
 ### Platform site
 
@@ -108,5 +147,7 @@ All plans in [docs/plans/](docs/plans/). Completed plans are kept as architectur
 | [favicon.md](docs/plans/favicon.md) | Complete |
 | [legal-page-generator.md](docs/plans/legal-page-generator.md) | Complete |
 | [url-redirects.md](docs/plans/url-redirects.md) | Complete |
-| [onboarding-ux.md](docs/plans/onboarding-ux.md) | Planned |
+| [onboarding-ux.md](docs/plans/onboarding-ux.md) | Planned (v2) |
+| [notification-overhaul.md](docs/plans/notification-overhaul.md) | Planned |
+| [live-site-editor.md](docs/plans/live-site-editor.md) | Design exploration |
 | [profit-aware-pricing.md](docs/plans/profit-aware-pricing.md) | Planned |
diff --git a/ROADMAP.md b/ROADMAP.md
index a778d2b..99a25f7 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -35,6 +35,26 @@ Complete cost visibility for shop owners. [Plan](docs/plans/profit-aware-pricing
 
 Email list collection (signup forms on shop pages). Campaign sending for product launches and sales. Simple to start: collect emails, send via Swoosh. Ties into sales & promotions for sale announcement blasts.
 
+## SEO settings
+
+Comprehensive SEO tooling to rival best-in-class WordPress plugins (Yoast, RankMath) and other 2026 best-of-breed SEO tools. Needs a full planning session to scope.
+
+Potential areas:
+- Per-page SEO scoring/analysis with actionable suggestions
+- Structured data / JSON-LD beyond the basics (FAQ, HowTo, product reviews, breadcrumbs)
+- XML sitemap with priority/frequency hints, image sitemaps
+- Canonical URL management, hreflang for multi-language
+- Open Graph and Twitter card previews in the editor
+- Internal link suggestions
+- Readability analysis
+- Search console integration
+- Redirect chains and broken link detection (partially done via URL redirects feature)
+- Core Web Vitals monitoring
+
+## Multiple print providers
+
+Support connecting multiple print providers simultaneously during setup and in general use. Route products to different providers based on product type, cost, or seller preference. Allow experimentation with providers before committing.
+
 ## Product page improvements
 
 - Pre-checkout variant validation (verify provider availability)
diff --git a/docs/plans/live-site-editor.md b/docs/plans/live-site-editor.md
new file mode 100644
index 0000000..29bc8c8
--- /dev/null
+++ b/docs/plans/live-site-editor.md
@@ -0,0 +1,152 @@
+# Live site editor
+
+Status: Design exploration
+
+A live, on-site editing experience where admins browse their real shop with an editing overlay. Change theme settings, edit page content, and adjust block settings — all while seeing the result immediately on the actual site.
+
+## Inspiration
+
+Squarespace, Webflow, Shopify's theme customiser. The common pattern: you're looking at your real site, with an editing panel alongside it. Changes apply live. No separate "admin preview" — what you see is what your customers get.
+
+## Core concept
+
+### Edit mode
+
+Logged-in admins see a small floating "Edit" button (or pencil icon) on their shop. Clicking it enters edit mode. This is invisible to regular visitors.
+
+### Layout by screen size
+
+**Mobile / small screens (< 768px):**
+- Full-width site view
+- Tap a block or element to select it
+- Bottom sheet or full-screen overlay slides up with settings for the selected item
+- Swipe down or tap outside to dismiss
+- A small floating toolbar stays visible (edit toggle, undo, save)
+
+**Tablet / medium screens (768px–1024px):**
+- Site view takes most of the width
+- Sidebar slides in from the left or right, narrower (250–300px)
+- Site content reflows to fit
+
+**Desktop / large screens (> 1024px):**
+- Split view: sidebar (350–400px) on the left, live site preview on the right
+- Sidebar has full settings panels
+- Site renders at remaining width, giving a realistic preview
+
+### What's editable
+
+**Theme settings (global):**
+- Preset picker (the 8 existing presets)
+- Colour tokens (primary, surface, text, accent)
+- Typography (font family, sizes, weights)
+- Layout settings (max-width, spacing)
+- Logo, header image, favicon
+
+These already work via CSS custom properties — changes can apply instantly client-side before saving, exactly like the current theme editor.
+
+**Page content (per-page):**
+- Block list: reorder, add, remove blocks
+- Block settings: layout, styling, images — shown in sidebar when a block is selected
+- **Inline text editing**: `contenteditable` for text content within blocks (headings, paragraphs, button labels). Edit directly on the page, changes sync back to block data via LiveView events.
+
+**Page settings:**
+- Title, slug, SEO metadata, publish status
+- Accessible from the sidebar when no block is selected
+
+### Interaction model
+
+1. **Click a block on the page** → block highlights (outline/overlay), sidebar shows that block's settings
+2. **Click text within a block** → enters inline editing mode (`contenteditable`). Sidebar shows block settings alongside.
+3. **Edit in sidebar** → changes apply live to the page (theme via CSS vars, blocks via LiveView re-render)
+4. **Sidebar tabs/sections:** "Theme" (global settings) and "Page" (current page's blocks and settings)
+5. **Save** → persists all changes. Unsaved changes indicator in toolbar.
+6. **Exit edit mode** → removes sidebar/overlay, back to normal browsing
+
+### How it relates to existing features
+
+The current admin already has:
+- **Theme editor** (`/admin/theme`): full theme customisation with preset picker, colour/font/layout controls
+- **Page editor** (`/admin/pages/:id/edit`): block list with drag-and-drop reorder, block settings panels, live preview
+
+The live site editor doesn't replace these — it re-surfaces the same components in a new context. The admin pages remain as the full-featured editing environment. The live editor is the quick, visual, "I just want to tweak this" experience.
+
+**Shared components:**
+- Theme setting controls (colour pickers, font selectors, preset cards)
+- Block settings panels (per block type)
+- Block list with reorder controls
+
+These need to be extracted into standalone components that work in both contexts (admin page and live editor sidebar).
+
+## Technical approach
+
+### LiveView architecture
+
+The live site editor would be a LiveView that:
+1. Renders the actual shop page content (blocks, theme) as the main view
+2. Has a sidebar component (LiveComponent or function component) for editing controls
+3. Manages edit state (selected block, unsaved changes, edit mode on/off)
+
+**Option A: Wrapper LiveView**
+A dedicated LiveView at e.g. `/edit/:path` that wraps the shop page rendering with the editor UI. The shop page content is rendered server-side just like normal, but wrapped in edit-mode markup.
+
+**Option B: Editor overlay on existing shop LiveViews**
+Inject the editor UI into the existing shop LiveViews when the user is an admin in edit mode. Cleaner URL story (you're editing at the same URL) but more coupling.
+
+Option A is probably cleaner for a first pass — less risk of breaking the shop experience.
+
+### Inline text editing
+
+`contenteditable` integration with LiveView:
+
+1. Block text content renders inside a `contenteditable` element with `phx-hook="InlineEdit"`
+2. The JS hook captures changes (on blur or on a debounce) and sends them back as LiveView events
+3. The LiveView updates the block data
+4. Need `phx-update="ignore"` on the contenteditable element to prevent LiveView from overwriting mid-edit
+
+This is achievable but needs careful handling of the LiveView ↔ JS boundary.
+
+### CSS custom property injection
+
+Theme changes already work by injecting CSS custom properties into `<style>` tags. The live editor can use the same mechanism:
+
+1. User changes a theme setting in the sidebar
+2. LiveView updates the CSS custom property value
+3. Browser applies it instantly (no page reload, no re-render needed for most changes)
+4. On save, persist to the database
+
+### Responsive sidebar
+
+CSS-based responsive layout:
+- `@container` queries or media queries to switch between split view and overlay
+- Sidebar as a fixed/absolute positioned element on small screens, part of the grid on large screens
+- Transition animations for sidebar open/close
+
+## Open questions
+
+- **URL routing:** `/edit/*` prefix? Or a query param like `?edit=true`? Or detect from session state?
+- **Permissions:** just the admin user, or could there be collaborator roles later?
+- **Conflict resolution:** what if someone edits in the admin panel while someone else uses the live editor? (Probably fine for single-user MVP, but worth noting.)
+- **Block types that aren't text:** image blocks, product grids, etc. — sidebar-only editing, no inline editing for these?
+- **Performance:** rendering the full shop page inside a LiveView with extra edit UI — any concerns?
+
+## Task breakdown (rough)
+
+This is a bigger feature. Rough phases:
+
+| Phase | Description | Est | Status |
+|---|---|---|---|
+| 1 | Design: sketch 2-3 approaches, pick one | 2h | planned |
+| 2 | Extract shared components from theme editor and page editor | 4h | planned |
+| 3 | Build the editor wrapper LiveView with sidebar shell | 3h | planned |
+| 4 | Theme editing in sidebar (re-use theme controls, live CSS vars) | 3h | planned |
+| 5 | Block list and block settings in sidebar | 3h | planned |
+| 6 | Block selection: click-to-select with highlight on page | 2h | planned |
+| 7 | Inline text editing with contenteditable + phx-hook | 4h | planned |
+| 8 | Responsive layout (split view ↔ overlay) | 2h | planned |
+| 9 | Save/discard/undo flow | 2h | planned |
+| 10 | Edit mode toggle (floating button for admins on shop pages) | 1h | planned |
+| 11 | Polish and testing | 4h | planned |
+
+Total estimate: ~30h
+
+This should be broken down further when we get to implementation. Each phase is roughly a session.
diff --git a/docs/plans/notification-overhaul.md b/docs/plans/notification-overhaul.md
new file mode 100644
index 0000000..bd0ae9a
--- /dev/null
+++ b/docs/plans/notification-overhaul.md
@@ -0,0 +1,172 @@
+# Notification system overhaul
+
+Status: Planned
+
+Replace floating toast/flash notifications with inline feedback and persistent top banners. Based on usability testing (March 2026) — flash messages overlay UI, auto-dismiss means users miss them, and the overall pattern feels messy.
+
+## Current state
+
+Phoenix flash messages shown as floating toasts. 110+ flash messages across 28 files (65 info, 45+ error). Auto-dismiss after a few seconds. Overlay existing UI content.
+
+## New approach: two layers
+
+### 1. Inline feedback (primary)
+
+Contextual to the field or action. Persistent until the state changes.
+
+- **Success:** green tick/label next to the saved field or action area. E.g. "Saved" next to a settings field after change.
+- **Error:** red border on the field + error text below it. Stays visible until fixed. Bold, clearly coloured, impossible to miss — same visual weight as validation errors.
+- **Loading/progress:** subtle indicator while an async action is in-flight (e.g. "Syncing..." next to sync button).
+
+Best for: form saves, field validation, toggle changes, individual actions.
+
+### 2. Top banner (page-level confirmations)
+
+For actions that affect the whole page or aren't tied to a specific field.
+
+- Bold, clearly coloured background: green for success, red for errors, amber for warnings
+- Non-overlapping: pushes content down (not an overlay)
+- **Persistent until manually dismissed** (click to close) — no auto-dismiss, because users may be looking elsewhere
+- Clear close button (x icon)
+- Positioned at top of the content area, below the header/nav
+
+Best for: "Products synced successfully", "Page saved", "Email provider connected", navigation-result confirmations, operation outcomes.
+
+### 3. No floating toasts
+
+Remove the floating toast pattern entirely. Between inline feedback and top banners, every use case is covered with better UX.
+
+## Migration plan
+
+### Category 1: Form saves → inline feedback
+
+These should become contextual inline confirmations near the action:
+
+| Current flash | Location | Inline replacement |
+|---|---|---|
+| "Theme saved successfully" | Theme editor | Green tick next to save button, brief "Saved" label |
+| "Email settings saved" | Email settings | Green tick/label near save area |
+| "Settings saved" | Provider form | Green tick near save |
+| "Navigation saved" | Navigation editor | Green tick near save |
+| "Page settings saved" | Page editor | Green tick near save |
+| "Metadata updated" | Media library | Green tick on the metadata form |
+| "Product updated" | Product show | Green tick near the field that changed |
+
+### Category 2: Validation errors → inline field errors
+
+Already partially in place via changesets, but some are flash-based:
+
+| Current flash | Location | Inline replacement |
+|---|---|---|
+| "Please enter your API token" | Setup wizard | Red border + error text on the API key field |
+| "Missing required fields: {labels}" | Email settings | Red border on each missing field |
+| "Please enter your Stripe secret key" | Settings | Red border + error on the Stripe key field |
+| "Please fill in all required fields" | Contact form | Red border on each empty required field |
+| "Please enter a valid email address" | Newsletter | Red border + error on email field |
+| "Please enter your email address" | Various | Red border + error on email field |
+| "Password must be at least 12 characters" | Setup recover | Red border + error on password field |
+| "Please enter a shop name" / "email address" | Setup | Red border on the relevant field |
+
+### Category 3: State changes → top banner
+
+These are page-level outcomes, best as persistent top banners:
+
+| Current flash | Location | Banner replacement |
+|---|---|---|
+| "Shop is now live" / "Shop taken offline" | Settings | Green/amber banner at top of settings |
+| "Connected to {provider}!" | Provider form | Green banner on the provider page |
+| "Email provider disconnected" | Email settings | Amber banner |
+| "Stripe connected and webhook endpoint created" | Settings | Green banner |
+| "Provider connection deleted" | Providers index | Green banner |
+| "Page saved" | Page editor | Green banner |
+| "Page deleted" / "Page created" | Pages index | Green banner |
+
+### Category 4: Operation outcomes → top banner
+
+Async or significant operations:
+
+| Current flash | Location | Banner replacement |
+|---|---|---|
+| "Sync started for {name}" | Providers/settings | Green banner with progress note |
+| "Connected! Product sync started in the background." | Setup | Green banner |
+| "Submission retry enqueued" | Activity log | Green banner |
+| "Image uploaded" / "Image deleted" | Media library | Green banner |
+| "Campaign is being sent!" | Newsletter | Green banner |
+| "Test email sent to {email}" | Email settings | Green banner |
+| "Added to basket" | Shop cart | Inline: brief confirmation near the add button or cart icon update |
+| "Removed from basket" | Shop cart | Inline: item visually removed, no separate message needed |
+| "Message sent! We'll get back to you soon." | Contact | Green banner above the form (or replace form with success state) |
+
+### Category 5: Auth/system messages → top banner (keep as-is pattern)
+
+These are inherently page-level and work fine as top banners:
+
+| Current flash | Location | Notes |
+|---|---|---|
+| "Welcome back!" | Login redirect | Green banner on dashboard |
+| "Logged out successfully" | Post-logout | Green banner on login page |
+| "Invalid email or password" | Login | Could be inline under the form, or red banner |
+| "User confirmed successfully" | Email confirm | Green banner |
+| "Your basket is empty" | Checkout | Redirect + banner or inline empty state |
+
+### Category 6: Error/failure messages → inline or banner
+
+| Current flash | Replacement |
+|---|---|
+| "Could not connect — check your API key" | Inline error on the API key field + help link |
+| "Stripe connection failed: {message}" | Inline error near Stripe key field |
+| "Failed to send test email: {reason}" | Inline error near the test email button |
+| "Upload failed" | Inline error near the upload area |
+| "Cannot delete — image is still in use" | Red banner with explanation |
+| "Something went wrong. Please try again." | Red banner |
+
+## Implementation
+
+### Phase 1: Build the notification components
+
+1. **Inline feedback component** — reusable component that shows success/error state next to any action. Props: status (success/error/loading), message, auto-clear timing (optional, for success only after state persists).
+2. **Top banner component** — replaces the current flash component. Pushes content down, persistent until dismissed, coloured by type.
+3. **Remove** the existing floating toast CSS/JS.
+
+### Phase 2: Migrate admin forms (highest impact)
+
+Start with the most-used admin pages:
+- Theme editor
+- Page editor
+- Settings
+- Email settings
+- Provider forms
+
+### Phase 3: Migrate remaining admin pages
+
+- Media library
+- Products
+- Activity log
+- Newsletter
+- Redirects
+- Navigation
+
+### Phase 4: Migrate shop pages
+
+- Cart (add/remove feedback)
+- Contact form
+- Checkout errors
+- Auth flows (login, registration, confirmation)
+
+### Phase 5: Migrate setup wizard
+
+Update the setup flow (ties into the onboarding-ux v2 plan).
+
+## Task breakdown
+
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| 1 | Build inline feedback component | 1.5h | planned |
+| 2 | Build persistent top banner component (replaces flash) | 1.5h | planned |
+| 3 | Migrate admin forms to inline feedback (theme, pages, settings, email, providers) | 3h | planned |
+| 4 | Migrate remaining admin pages (media, products, activity, newsletter, redirects, nav) | 2h | planned |
+| 5 | Migrate shop pages (cart, contact, checkout, auth) | 2h | planned |
+| 6 | Migrate setup wizard notifications | 1h | planned |
+| 7 | Remove old flash/toast CSS and JS | 30m | planned |
+
+Total estimate: ~11.5h
diff --git a/docs/plans/onboarding-ux.md b/docs/plans/onboarding-ux.md
index 34210a2..7a9f9ea 100644
--- a/docs/plans/onboarding-ux.md
+++ b/docs/plans/onboarding-ux.md
@@ -1,109 +1,168 @@
-# Onboarding UX improvements
+# Onboarding UX v2
 
 Status: Planned
 
-## Context
+Supersedes the original onboarding-ux plan. Based on usability testing session (March 2026) covering the setup wizard, launch checklist, email provider setup, and general onboarding flow.
 
-The setup wizard and dashboard launch checklist work, but there are gaps that leave new users guessing. Goal: make onboarding totally fool-proof and guided so a non-technical seller can go from zero to live store without confusion.
+## Vision
+
+A non-technical seller should be able to go from zero to a live shop without confusion or frustration. The setup should feel like one cohesive journey, not a scavenger hunt through admin pages. Every step should explain *why* it's needed, be forgiving of mistakes, and never leave the user stranded.
 
 ## Current flow
 
-1. **Setup wizard** (`lib/berrypod_web/live/setup/onboarding.ex`): 3 cards — admin account → provider API key → Stripe connection. Gated by secret in prod, auto-login after account creation.
-2. **Dashboard checklist** (`lib/berrypod_web/live/admin/dashboard.ex`): 5 items with progress bar — sync products, connect Stripe, customise theme, place test order, go live. Visible when `site_live` is false and not dismissed.
+1. **Setup wizard** (`lib/berrypod_web/live/setup/onboarding.ex`): 3 cards — admin account, provider API key, Stripe connection. Gated by secret in prod, auto-login after account creation.
+2. **Dashboard checklist** (`lib/berrypod_web/live/admin/dashboard.ex`): 5 items with progress bar. Visible when `site_live` is false and not dismissed.
 3. **Coming soon page**: blocks public access before launch.
 4. **Setup status** (`lib/berrypod/setup.ex`): `setup_status/0` returns booleans for each milestone.
 
-## Gaps identified
+## What changes
 
-### High priority
+### A. Simplify initial setup to account creation only
 
-#### 1. Dead end after setup wizard
-The wizard ends at Stripe connection with no redirect or next-steps message. User has to figure out where to go.
+The first screen should be dead simple and low-friction: email, password (with confirmation field), shop name. That's it. No provider keys, no Stripe.
 
-**Fix:** After completing the final wizard step, redirect to `/admin` with a flash message like "You're in! Here's your launch checklist." (~30m)
+- Live validation on all fields (email format, password strength/match, shop name not blank)
+- Note under shop name: "You can change this later"
+- On submit: create account, log in, redirect to the guided setup flow
 
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`
+Email/password correction after this point is just normal admin account settings — no special "go back to setup" needed.
 
-#### 2. No shipping rate setup in checklist
-Checkout requires shipping rates. There's no checklist item for configuring shipping, and no warning that checkout will fail without it. A user could "Go live" with no shipping rates.
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, possibly `lib/berrypod_web/live/admin/settings.ex`
 
-**Fix:** Add "Set up shipping" checklist item that links to `/admin/settings` (shipping section). Gate "Go live" on at least one shipping profile existing. (~1h)
+### B. Guided setup flow with progress bar
+
+After account creation, the user enters a single multi-step guided journey. This replaces the current approach of separate admin pages.
+
+**Intro screen** — before any steps, briefly explain what Berrypod does and why you need each thing:
+
+> "Berrypod connects your print-on-demand products to your own online shop. To get fully set up, you'll need three things:
+>
+> - A **print provider** account (like Printify or Printful) to make and ship your products
+> - A **Stripe** account to accept payments from customers
+> - An **email provider** account so your shop can send order confirmations and shipping updates"
+
+Then the steps with a clear progress bar at the top. Each step shows: step number, title, whether it can be skipped, estimated time.
+
+**Steps:**
+1. **Connect print provider** — allow connecting multiple providers (not forced to pick just one). "Skip for now" available.
+2. **Connect Stripe for payments** — "Skip for now" available.
+3. **Set up email provider** — "Skip for now" available.
+
+Each step embeds the same settings UI components that live in the admin pages (shared, not duplicated). The guided flow adds extra context and hand-holding around them.
+
+On completion (or after skipping all): redirect to dashboard with clear status messaging.
+
+**Key UX decisions:**
+- Progress bar visible at all times, showing completed/current/upcoming steps
+- Each step has a "Skip for now" with a brief, non-naggy note about what won't work without it
+- External service links (create Printify account, etc.) open in new tabs with external-link icon and aria label
+- Users can go back to previous steps to correct mistakes
+- If revisiting (e.g. after closing browser), detect existing state via `Setup.setup_status/0` and resume from the first incomplete step
+
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod/setup.ex`, new shared components
+
+### C. Forgiving API key validation
+
+API key entry should be as forgiving as possible:
+
+- Auto-strip leading/trailing whitespace on paste and submit
+- Validate format where known:
+  - Printify: 36-character UUID format
+  - Printful: specific prefix/length
+  - Stripe: must start with `sk_live_` or `sk_test_`
+  - Email providers: provider-specific format checks
+- Specific, helpful error messages: "This looks too short — Printify API keys are usually 36 characters" rather than generic "Invalid"
+- Validate on blur for fast feedback, not just on submit
+- Link to where to find the key: "Find your Printify API key at Settings > Connections"
+
+**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod_web/live/admin/providers.ex`, validation logic in contexts
+
+### D. Email provider setup UX
+
+Rework the email provider selection and configuration:
+
+- **Recommended pick** highlighted at top — whichever has the best free tier, easiest setup, and supports newsletters. One clear "if you're not sure, pick this" option.
+- **Two groups:** "Also sends newsletters" vs "Transactional only" with one-line explanation of the difference
+- **One-liner per provider:** free tier info, setup difficulty ("paste one API key" vs "requires domain verification")
+- **Self-hosted/SMTP** in a collapsible "Advanced" section at bottom
+- **Guided flow after selection:** link to create account (new tab), then "Now enter these settings:" with config fields
+- **Send test email** button after configuration
+- **Remove** the masked key display ("Current: 84159e26•••4f3")
+- **Default from address** to the admin email automatically — don't surface during setup, it's a general settings thing for later
+
+**Files:** `lib/berrypod_web/live/admin/email_settings.ex`, shared components for guided flow
+
+### E. Contextual prompts for skipped steps
+
+When a step is skipped, surface the need where it matters — once per context, never as global nags:
+
+- **Products page** (no print provider): empty state explaining why products are empty, with link to connect a provider
+- **Cart/checkout** (no Stripe): checkout button disabled with explanation and link to connect Stripe
+- **Order detail** (no email provider): note saying "Order confirmation emails aren't being sent. Set up an email provider to send them automatically."
+- **Dashboard checklist**: always shows outstanding items regardless of skips
+
+Principle: explain what's missing, link to the fix, one instance per context.
+
+**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod_web/live/shop/` (various), `lib/berrypod_web/components/`
+
+### F. Dashboard checklist and messaging
+
+Rework the dashboard checklist to match the guided setup flow:
+
+- **Before setup complete:** "Your admin account has been created. Continue the full setup below." with checklist of outstanding items
+- **After all steps done and site live:** "Your shop is live! Ready to go"
+- Checklist item names match the setup wizard step names exactly (no mismatches)
+- Each checklist item links to its admin settings page (for when they return outside the wizard)
+- Help/FAQ links next to items involving API keys or complicated config
+- Collapsible rather than dismissable (can always get it back)
+- Shipping setup and shop settings as additional checklist items (carried forward from v1 plan)
 
 **Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
 
-#### 3. No shop settings in checklist
-Shop name, currency, country are critical but not in the checklist. User could go live with "My Shop" as the name.
+### G. Coming soon page fixes
 
-**Fix:** Add "Configure your shop" as the first checklist item, linking to `/admin/settings`. Mark complete when shop name differs from default. (~45m)
+- Fix logo displaying oddly to the side
+- Add a subtle "Admin login" link (footer or corner)
 
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
+**Files:** `lib/berrypod_web/live/shop/coming_soon.ex`, associated template
 
-### Medium priority
+### H. External links UX
 
-#### 4. Checklist dismissable and gone forever
-Once dismissed, no way to get it back. Stored as `checklist_dismissed` setting.
+All links to external services throughout the app get:
+- `target="_blank"` + `rel="noopener noreferrer"`
+- Small external-link icon
+- Aria label indicating it opens in a new window
 
-**Fix:** Replace dismiss with a collapse/expand toggle. Or add a "Show launch checklist" link in the dashboard sidebar when dismissed but site isn't live yet. (~15m)
+**Files:** templates throughout `lib/berrypod_web/`
 
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, possibly `lib/berrypod_web/components/layouts/admin.html.heex`
+### I. Input styling — WCAG compliance
 
-#### 5. "Place a test order" has zero guidance
-Links to the shop home page. No mention of Stripe test mode, test card numbers, or what a successful test looks like.
+Increase input field border contrast to meet WCAG AA (3:1 minimum for UI components), aim for AAA. Clear, visible field edges in all contexts.
 
-**Fix:** Add inline help text under the checklist item: "Use card number 4242 4242 4242 4242 with any future expiry and CVC. You'll see the order appear in Orders when it works." (~45m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 6. Skip completed wizard steps on revisit
-If a user closes their browser mid-setup and comes back, the wizard restarts from scratch (session-based). Should detect existing state and skip completed steps.
-
-**Fix:** In `mount/3`, call `Setup.setup_status/0` and set `current_step` to the first incomplete step. (~1h)
-
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`
-
-#### 7. Better provider connection error messages
-If the API key is wrong, the error is generic. No link to where to find the key, no troubleshooting.
-
-**Fix:** Add provider-specific help text: "Find your Printify API key at Printify → Settings → Connections" (with link). Show the actual API error when it's user-facing (auth failure vs server error). (~30m)
-
-**Files:** `lib/berrypod_web/live/setup/onboarding.ex`, `lib/berrypod_web/live/admin/providers.ex`
-
-### Low priority
-
-#### 8. Guide theme customisation
-`theme_customised` is true if any setting differs from defaults. Changing one colour counts. No guidance on what to customise.
-
-**Fix:** Add a brief tip under the checklist item: "Upload your logo, pick your colours, and choose a font that matches your brand." (~15m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 9. Clarify "Sync your products" checklist step
-Links to `/admin/providers` but user needs to click "Sync" on an already-connected provider. Confusing if they connected during the wizard.
-
-**Fix:** If provider is connected but no products synced, link directly to the provider detail page with a prompt to sync. If products exist, mark as complete. (~15m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`
-
-#### 10. Move email setup into checklist as optional step
-The orange "email not configured" banner appears on every page but isn't in the checklist. Email is needed for abandoned cart, order confirmations, contact form.
-
-**Fix:** Add as a non-blocking checklist item (doesn't gate "Go live" but shows as recommended). (~30m)
-
-**Files:** `lib/berrypod_web/live/admin/dashboard.ex`, `lib/berrypod/setup.ex`
+**Files:** `assets/css/admin/components.css`, `assets/css/shop/` CSS files
 
 ## Task breakdown
 
-| # | Task | Priority | Est | Status |
-|---|------|----------|-----|--------|
-| 1 | Redirect to dashboard after wizard completion with welcome flash | High | 30m | planned |
-| 2 | Add shipping setup to checklist, gate "Go live" on shipping existing | High | 1h | planned |
-| 3 | Add shop settings to checklist (name, currency) | High | 45m | planned |
-| 4 | Make checklist collapsible instead of dismissable | Medium | 15m | planned |
-| 5 | Add test order guidance (test card number, what to expect) | Medium | 45m | planned |
-| 6 | Skip completed wizard steps on revisit | Medium | 1h | planned |
-| 7 | Better provider connection error messages with help links | Medium | 30m | planned |
-| 8 | Add theme customisation tips to checklist | Low | 15m | planned |
-| 9 | Smarter "Sync products" checklist link | Low | 15m | planned |
-| 10 | Add email setup as optional checklist item | Low | 30m | planned |
+| # | Task | Est | Status |
+|---|------|-----|--------|
+| A | Simplify initial setup to account creation only | 1.5h | planned |
+| B | Guided setup flow with progress bar | 4h | planned |
+| C | Forgiving API key validation | 1.5h | planned |
+| D | Email provider setup UX rework | 2h | planned |
+| E | Contextual prompts for skipped steps | 2h | planned |
+| F | Dashboard checklist and messaging rework | 2h | planned |
+| G | Coming soon page fixes (logo + admin link) | 30m | planned |
+| H | External links UX (new tabs, icons, aria) | 1h | planned |
+| I | Input styling — WCAG compliance | 1h | planned |
 
-Total estimate: ~5.5h
+Total estimate: ~15.5h
+
+## Suggested order
+
+1. **A** first — simplify the entry point
+2. **B** — the big piece, the guided flow
+3. **C** — validation improvements (can be done alongside B)
+4. **D** — email provider UX (part of the guided flow)
+5. **F** — dashboard checklist rework (depends on the flow being defined)
+6. **E** — contextual prompts (depends on knowing what's skippable)
+7. **G, H, I** — smaller fixes, can be done any time