Use case · SaaS
A SaaS product is not a set of screens. It is a subscription, a customer, an invoice, an administrator and the rules that connect them. Echo plans those pieces together, builds them in parallel, and verifies the result in a browser before you ship it.
01 / The four pieces
Name these explicitly in the brief and the planner treats them as first-class work. Leave them vague and you will find them later, in the least convenient place.
Sign up, sign in, sign out, reset a password, and a signed-out visitor who lands on a protected route is returned to where they were going. Then decide how many roles exist. Two is usually enough at the start; a permissions system you did not ask for is a permissions system you have to maintain.
A plan choice, a checkout, a success state, a cancelled state, and a place in the product where the current plan is visible. Connect a payment provider as a plugin rather than re-implementing card handling, so you get a real checkout flow and a clean boundary between what you built and what the provider handles.
Say what things are and how they relate in plain language — "an invoice belongs to a client and has many line items", "a user belongs to one workspace" — and let the planner turn it into tables. Ownership rules belong here too, not in a security page you write later.
A brand-new account has an empty workspace. Every list needs an empty state that tells the user what to do next. Every form needs an error state. Every permission needs a denied state. These are cheap to specify and expensive to retrofit.
02 / Scope
An AI builder will not push back on an over-broad brief — it will dutifully generate four months of features, and you will spend those four months deleting code. For most B2B SaaS products, the list of exclusions is longer than the list of inclusions.
A brief that says “two roles only: admin and member, decided at signup” produces exactly that. A brief that says “roles” produces a permissions system.
03 / The first build
A flow forces the builder to decide what happens between the pages. One complete flow also gives you something you can demo to a real customer in a week.
Build an invoicing app for freelance studios. A user signs up, lands in an empty workspace, creates their first client, creates an invoice for that client, sees it listed as unpaid, and can mark it paid. Admins can see every invoice in the workspace; members only see their own. Invoice: number, client, issue date, due date, status (unpaid, paid, overdue), and a list of line items with description, quantity and price. Pages: invoices list, invoice detail, clients, settings. Visual direction: quiet, dense, mostly tables, no illustrations. Skip tax calculation and payment collection — show a status field only.
Echo plans that into a route graph, a data model and a set of screens that agree with each other — and then builds it.
04 / Before you launch
Then reset your password, then sign out and back in.
Then try to create one with a missing required field, so you see the error state you did not think about.
Zero items, one item, many items. That is where layouts break.
Nothing private should be visible to a signed-out visitor.
Environment variables, routes, accessibility and a security scan — read every finding, not only the summary.
Start free, review the plan before the code exists, and export the source whenever you want it.