You've got the idea. You've got the validation conversations. You've maybe even got a technical co-founder raring to go. And now everyone's asking the same question: when do we start building?

Here's the honest answer: not yet.

Building before you've locked down your design is one of the most expensive mistakes in software as a service for startups. Not because design is precious, but because code is slow to change. A wireframe takes 20 minutes to revise. The same change in production can take two weeks and three engineers. The decisions you make (or skip) before your first commit ripple through your entire product.

This isn't a case against moving fast. It's a case for moving fast on the right things first. Here's what to design and validate before a single line of code gets written.

Why Pre-Code Design Saves Money (Not Just Time)

There's a persistent myth in startup culture that shipping fast means skipping design. That's conflating two things. Shipping fast means getting to validated learning as quickly as possible. Design, done right, accelerates that. It lets you test assumptions, spot broken flows, and catch usability disasters when they're still just boxes on a screen.

The founders who skip this step often end up in the same place: three months into development, realizing that their core user flow requires a database restructure they didn't anticipate because no one mapped out what the screens actually needed to do.

Design decisions made in wireframes cost pennies. The same decisions made in production cost dollars. For software as a service startups operating lean, that math matters a lot.

1. Map the Complete User Flow First

Before you think about what a screen looks like, you need to know every screen that exists. A user flow isn't a feature list. It's a step-by-step path from "just arrived" to "core value delivered."

Grab a whiteboard (or Figma, or even paper) and map it out literally:

• How does a user sign up?
• What's the first thing they see after confirming their email?
• What action do they need to take to get value from your product?
• What happens if they make a mistake or skip a step?
• How do they come back after a week away?

You'll almost immediately find gaps you hadn't thought about. The confirmation email flow. The forgot-password screen. The edge case where a user tries to complete step three before step two is done. These aren't edge cases. They're your product. Every gap in the user flow is a place a real person will get stuck.

A complete user flow also forces a critical question: is your product actually as simple as you think it is? Many founders discover at this stage that what felt like a lean MVP is actually a much more complex system. Better to know now.

2. Decide Your Core UX Model

Your core UX model is the underlying structure your product lives inside. It's the mental model you're teaching your users. And it's one of the hardest things to change once you've built it.

Think about the difference between a product organized around projects (like Notion or Asana) versus one organized around a global feed (like Twitter or Slack). These are fundamentally different UX models. The navigation, the data structure, the way users build habits: all of it flows from this one decision.

For software as a service startups, the most common UX models are:

Dashboard-first: Users land on an overview with quick stats and actions. Good for products where the user needs to monitor something.

Object-first: Users land in a list of the main "thing" in your product (contacts, projects, documents). Good for products that are fundamentally about managing a collection.

Feed-first: Users land in a chronological or algorithmic stream. Good for collaboration or communication tools.

Setup-first: Users are immediately walked through configuration before they see the main product. Good for tools that require personalization to work.

Pick your model in wireframes. Sketch out what the nav structure looks like, what lives where, and how a user moves between major sections. Then test it by walking three or four people through it. You want to hear "oh, that makes sense" instead of "wait, where am I?"

3. Design Your Onboarding Before Anything Else

Onboarding is the highest-stakes UX you'll ever design. It's the five-minute window in which a new user either gets it or doesn't. For SaaS products, that five minutes determines whether they come back at all.

Most early-stage teams treat onboarding as an afterthought. They build the core product, then slap a quick-start guide on top. That's backwards. Onboarding should be designed first because it reveals something important: if you can't walk a new user to their first "aha" moment in a handful of steps, your product might be too complicated to explain.

Design your onboarding flow in wireframes and actually walk through it. Ask:

• How many steps does it take to get from signup to first value?
• What's the minimum information you actually need from the user at sign-up?
• Where are users likely to drop off?
• What happens if a user skips a step?

This is also where you should start thinking about SaaS onboarding UX patterns and how they apply to your specific product. The patterns exist because they work: empty checklists, progress bars, interactive tooltips. But they only work if the underlying flow is sound.

Ready to stress-test your onboarding with a senior product designer? Book a call and we'll walk through it with you.

4. Design Your Empty States

Empty states are the screens your users see when they haven't done anything yet. They're also some of the most overlooked screens in early-stage products, and some of the most important.

An empty state is a moment of anxiety or opportunity depending on how you design it. When a user logs in for the first time and sees a blank screen with no direction, anxiety wins. When they see a clear prompt like "You don't have any projects yet. Create your first one in 30 seconds," opportunity wins.

Every major section of your product that can have zero items needs an empty state. Design these before you build:

• Empty list view: What does the screen look like when there's no data?
• Empty search results: What does the user see when their search finds nothing?
• Post-delete state: What happens to the screen after a user deletes the last item?
• First-run dashboard: What does the dashboard look like before any data has been added?

The reason to design these before coding is practical: empty states often require UI components that don't exist in your main screens. If you discover this during development, you'll either delay launch or ship a janky placeholder. Design them now.

5. Wireframe Your Three Most-Used Screens

After the user flow, the UX model, and the onboarding, you should wireframe the handful of screens your users will return to every single day. These are your recurring screens, the bread and butter of your product.

For most SaaS tools, these are:

• The main dashboard or home screen
• The primary list or overview (projects, contacts, tasks, whatever)
• The detail or edit view (the screen where the actual work happens)

These three screen archetypes are what your users will spend 80% of their time inside. They're also where you'll make the most consequential design decisions: table vs. card view, inline editing vs. modal editing, single-panel vs. split-panel layout.

Sketch them in low-fidelity wireframes. Don't worry about pixels or polish. Focus on layout, hierarchy, and how actions are surfaced. Then do a 15-minute usability test with someone who hasn't seen the product. Watch where their eye goes first. Watch what they click. The surprises at this stage are cheap to fix.

6. Decide What You're NOT Building

This sounds obvious but it's genuinely hard: design is also about defining the boundary. Before you start building, you need to know which screens and features are explicitly out of scope for version one.

The temptation to keep adding is real. Once you start designing, you'll see all the places where a small feature would make things better. Resist. Every feature you add before launch is a feature that slows you down, adds complexity to your onboarding, and might not be what users actually need.

The right way to handle this in wireframes is to mark the boundaries explicitly. When you're designing a screen and you think "we could add X here," note it as a future-state feature and move on. Having a visual record of what you deliberately chose not to build is valuable. It keeps scope creep from sneaking in under the radar.

Putting the Checklist Together

Here's the pre-build design sequence in order:

1. Full user flow: every screen, every path, every edge case mapped
2. Core UX model: navigation structure, information architecture
3. Onboarding wireframes: from sign-up to first value
4. Empty states: for every section that can be empty
5. Three key recurring screens: the ones users return to daily
6. Out-of-scope definition: what v1 explicitly does not include

This is roughly two to three focused design sprints. If you want to understand what design sprints look like in practice, that's worth reading before you dive in.

The teams that skip this process don't move faster. They just defer the rework. A few weeks of design before coding often saves months of engineering time. Jamm works with founders at exactly this stage: pre-build design reviews, wireframe validation, UX model sanity checks. It's one of the highest-leverage investments you can make in your product.

Think your pre-build checklist is solid? Or still figuring out where to start? Start your design subscription and put a senior product designer on your side from day one.