—
4
Min
Read
Most SaaS apps take months to design when they could take weeks. The time goes into designing every screen at once, then handing engineering a Figma file that still has to be rebuilt in code.
Here's the process I use instead: design the one workflow that matters first, build it on an existing component base, and test a working prototype before your team writes production code.
Key Takeaways
Start with the one job your app has to do, not the full feature list.
Five focused interviews are enough to start designing.
Map the core flow in boxes before you design a single screen.
Start from a component library and spend your design time on decisions, not buttons.
A working React prototype replaces the handoff and catches what a static mockup hides.
Settings, edge cases and a polished marketing site can wait until after launch.
What should you design first in a SaaS app?
The job your app is hired to do, in one sentence. Name the user and the task, and design for that before anything else.
Most teams start with a feature list. The list grows, every feature feels important, and design turns into a negotiation.
One clear job cuts that short. Talk to five people who'd use the product every day. Not a research phase that runs for weeks. Five focused conversations about what they do today and where it hurts.
Ask yourself:
Who uses this every day? Often it's not the person who buys it.
What are they doing today instead: a spreadsheet, email, a tool they hate?
What's the moment they'd notice it saved them time?
What could you cut and still deliver that moment?
If you can't say the job in one sentence, you're not ready to design screens.
Map the core workflow before you design any screens
Sketch the happy path as boxes and arrows: the 5–8 steps a user takes to finish the core job. This is where you find the screens you don't need.
It takes an hour on paper or in FigJam. It saves weeks later, because most bloated products are workflows that have quietly gotten too complex, and the flow is the cheapest place to stop that.
Use:
One flow per job, happy path first
A star on the screen where the user makes their main decision
A note on what data each step shows
Edge cases parked in a list, not in the flow
Every box you remove here is a screen you never have to design, build or maintain.
Do you need a design system for a SaaS MVP?
You need a small one, not a custom one. Start from an existing component library like shadcn/ui, then set a short list of tokens your whole app uses.
Buttons, inputs, tables and modals are solved problems. Designing them from scratch before launch is time you won't get back. Spend your design time on the decisions that make the product yours.
Use:
An existing React component library as the base
A type scale and a spacing scale
One accent color, not three
The same token names in Figma and in code, so you keep Figma and code in sync
Users will never notice your custom button. They'll notice a confusing flow.
Design the key screens first, at full quality
Design the main decision screen first, to final quality. Once it works, the rest of the app can be assembled from the same components and patterns.
This is where visual hierarchy matters most. The user should know where to look first and what to do next.
When I designed the project management UI system, I started with the project board. Once it worked, it set the layout, density and filters for every other screen.
Instead of 30 screens at mid-fidelity:
Design 3 key screens to final quality
Fill them with realistic data, not lorem ipsum
Design the empty state and the overloaded state
Give each screen one primary action
One great screen sets the pattern for the next twenty.
Why a working prototype beats a Figma handoff
A working React prototype is the most efficient handoff there is. Users test real behavior instead of pictures, and engineers start from code instead of redlines.
A Figma prototype shows what the app looks like. A coded one shows how it behaves: loading and error states, real data, how the layout holds up on a small laptop screen.
AI made this step cheap. With the Claude Code workflow I use to build them, a clickable prototype of the core workflow takes a few days instead of a full development sprint.
On a project for a Series A B2B SaaS team, the main board looked clean in Figma with a handful of sample items. Once the prototype ran on real data, there were hundreds of them, and the board got too crowded to scan.
We reworked the layout while it was still a prototype. A static mockup would never have shown that.
Add:
Real states: loading, error, empty
3–5 sessions with people who match your users
A note every time someone hesitates
Fixes in the prototype the same day
The same prototype doubles as a demo that shows one workflow well, for sales calls and investor meetings.
Mockups get approved. Prototypes get tested.
What can you skip until after launch?
Anything that doesn't help a user finish the core job. Efficient design is mostly deciding what not to design yet.
Every item below is worth doing eventually. None of it should slow down your first release. One thing I skip entirely, which most designers wouldn't: mid-fidelity wireframes. Once the flow is sketched, I go straight to final-quality key screens on the component base.
Skip for now:
Settings and admin screens beyond the basics
Dark mode
A native mobile app, unless your users are mobile-first
Custom illustrations and motion
A 10-page marketing site. A simple landing page is enough until the product proves itself.
Ship the core, then let users tell you what's next.
The slow way vs. the efficient way to design a SaaS app
Step | The slow way | The efficient way |
|---|---|---|
Research | Weeks of interviews and persona decks | 5 focused interviews and one job statement |
Scope | Every feature on the roadmap | One core workflow, 5–8 screens |
Design system | Custom-built before launch | Component library plus a short token list |
Visual design | Every screen at mid-fidelity | 3 key screens at final quality |
Testing | After engineering builds it | 3–5 users on a working prototype first |
Handoff | Figma file and specs | React prototype engineers build from |
Frequently asked questions
How long does it take to design a SaaS app?
Agencies usually quote 8 to 14 weeks for an MVP. For the core workflow, I usually go from kickoff to a prototype tested with real users in about two weeks.
Can you design a SaaS app with AI tools alone?
AI builds fast, but it defaults to the same generic layouts. You still need someone deciding what goes first, what gets cut and how the product should feel.
Final thoughts
AI made building cheap. That changed what the expensive mistake is. It used to be building slowly. Now it's building the wrong thing well.
Efficient design means making the few decisions that matter early, and proving them in a prototype before anyone writes production code.
What this gets you:
Real users testing your core workflow in weeks
Fewer engineering rewrites
A product you can demo to customers and investors
Design budget spent on the screens users actually touch
Project Inquiries
Book a call and walk me through the one job your app needs to do. I'll design that workflow and turn it into a working React prototype your team can test and build from.
