Nimo onboarding makeover
Show value before asking for commitment.
The current local flow works, but it turns into setup too quickly: sign in, enter websites, connect alerts, choose schedule, then wait. The makeover should teach the product model while creating an immediate first win before the paywall.
What the reference teaches
The supplied inspiration page is effective because it explains one model in plain language, gives compact choices, and ties every ask to value the user just received.
Reference screenshot
The useful pattern is not the visual style alone. It is the rhythm: thesis, model, choices, then concrete next actions.
Current flow health
Captured locally on August 16, 2026. Auth and onboarding API calls used a local mock server with canned responses so the UI could advance; no real Slack, Telegram, billing, audit, or production account was used.
Landing page: clear URL entry and product promise
The first screen does promise a site-speed check and includes a URL field. The page also has educational sections lower down, but a signup user may not carry that learning into auth.
Sign in: clean, but context-free
The screen is calm and usable. It does not preserve the motivation from the landing page: no promise of what happens next, no preview of the first payoff, and no reminder that this takes seconds.
Magic link sent: status only
This confirms the action, but the waiting state could explain what nimo will prepare: field data, Lighthouse diagnostics, first fix, and how the audit will be verified.
Websites: asks for data before showing why
The email-domain prefill is useful. The screen should translate “add up to 3” into value: “we’ll benchmark the pages that cost you signups,” “homepage plus pricing/signup,” or “paste one URL and we’ll suggest the rest.”
Chat and alerts: integration value is undersold
Telegram and Slack are presented as plumbing. The reference suggests making Slack a value signal: “send the first finding where your team can act on it,” with skip preserved for users who just want the report.
Schedule: simple control, weak payoff
Weekly is a sane default, but scheduling before the first result feels administrative. This should come after a small success state: queued audit, likely page type detected, or first quick insight.
Makeover direction
Keep the app’s restrained visual system, but change the sequence from “configure nimo” to “understand your first performance opportunity.”
Recommended new flow
The product should ask second.
Use the signup path to prove the core loop: find the slowdown, explain it, send it where work happens, and verify the next audit. Then the paywall is attached to more value, not access to understanding.