How much does a SaaS product redesign cost?

A product redesign is not a website redesign

A marketing website redesign changes how you present the product to prospective customers: positioning, page structure, visual identity and the path to a demo or sign-up. A product redesign changes the software your customers use every day: the screens, workflows and logic they rely on to get work done.

They are priced differently because the work is different. A marketing site is mostly a set of pages with a limited number of states. A single product screen can behave differently for each role, each data condition and each step in a process, and every one of those variations needs a design decision. A quote for one tells you very little about the other.

What “redesign” can mean

The word covers several very different pieces of work. The table compares the common types by what changes, what you should expect to receive and what makes each one larger or smaller. It deliberately has no price column: the same type of work varies widely in size from one product to another.

Implementation is often quoted separately because its size depends on your codebase as much as on the design. At Exalt, a Fixed-Price Project can include developer-ready handoff or agreed implementation in code, and larger front-end builds are scoped separately after reviewing your requirements and codebase.

What drives the scope

Two redesigns with the same number of screens can differ widely in effort. These are the factors that usually explain the difference.

Workflows

Count tasks, not screens. A task such as “invite a teammate and set their access” may cross four screens, an email and a settings page. Designing it properly means designing the whole sequence, including what happens when someone stops halfway.

Roles and permissions

Each role that sees a different version of a screen adds design work. Admins, standard users, read-only viewers and external guests may need different actions, empty states and messages on what looks like the same page.

States and edge cases

Every data-driven screen has more than one state: loading, empty, partially complete, failed, no permission, very long content, thousands of rows. In B2B software these states are often a large share of the design work, and they are the easiest thing for a cheaper proposal to leave out without saying so.

Research

If the problem is already well understood from support tickets, analytics or customer calls, little new research may be needed. If nobody is sure why users struggle, some interviews or usability testing before design can prevent expensive rework. Either way, the proposal should say which it assumes.

Component reuse

A product with a consistent component library in code is quicker to redesign than one where each area was built differently. If a design system has to be created or rebuilt as part of the work, that is a significant deliverable in its own right.

Responsive requirements

Many B2B products are used mainly on desktop, but some tasks, such as approvals or quick look-ups, need to work on a phone. Adapting a dense table or editor to a small screen is real design work, so agree which workflows need it.

Implementation

Handing designs to your engineers, supporting them during the build and building the front end yourself are three different levels of involvement. Check which one a price includes.

What a redesign proposal should include

A proposal you can rely on describes the work clearly enough that two people reading it would agree on whether a request is in or out. Look for:

• The problem being solved, in the provider’s own words.
• The workflows, roles and platforms in scope.
• Which states and edge cases will be designed.
• Research and validation activities, or a clear note that none are included.
• Deliverables, their format and level of detail.
• Milestones, review points and how feedback is handled.
• What handoff or implementation support is included.
• What happens if the scope changes partway through.

Some work is commonly priced separately, which is fine as long as the proposal says so: front-end implementation, a full design system, copywriting, illustration, marketing pages and support after launch.

How to compare two proposals

When two quotes differ significantly, the difference often comes down to scope rather than efficiency. Before comparing prices, put the proposals side by side and check:

1. Workflows. Do both cover the same tasks, not just the same pages?
2. Roles and states. Does one design only the default state for one role?
3. Research. A proposal that includes interviews or testing is doing different work from one that does not.
4. Deliverables. A tested prototype and a set of static screens are not equivalent.
5. Implementation. Is the price for designs, designs plus build support, or working code?
6. People. Who does the work, how senior are they, and how much of their time is included?

If a lower quote leaves out states or research the product needs, that work has not disappeared. It tends to reappear during development, when decisions get made in code under time pressure.

If you expect design work to continue after the redesign rather than end with it, a monthly arrangement may suit you better than a project. In-house designer, agency or embedded design partner compares the options.

How to reduce scope responsibly

A smaller budget is a reason to design less of the product, not to design it less thoroughly. Useful ways to narrow the scope:

• Redesign one complete workflow rather than restyling many screens.
• Design fully for the role that uses the workflow most, then treat other roles as variations.
• Keep existing components that work, and redesign only those causing problems.
• Use the evidence you already have, such as support themes, analytics and sales feedback, before commissioning new research.
• Phase the work: design the first workflow, ship it, then decide on the next.

What not to cut: the empty, error and permission states of the workflow you are redesigning, and enough validation to know the new design works. Removing those does not make the work cheaper, only less finished. How to scope a SaaS redesign without rebuilding everything explains how to draw that boundary.

Two screens that look alike

Two products each want a redesigned orders table. Both briefs say the same thing: one table, with search, filters and a detail panel.

Product A is used by one team. Everyone sees every order, orders are edited one at a time, and the list rarely exceeds a few hundred rows.

Product B has admins, regional managers and read-only finance users. Regional managers see only their region’s orders. Orders can be updated in bulk, some fields lock once an invoice is issued, and larger customers have tens of thousands of orders that load in pages.

Product B needs designs for each role’s view, the rules and messages for locked fields, bulk updates that succeed for some orders and fail for others, and slow or very large result sets. A screenshot of the default state could look almost identical for both products. The work behind it is not.

Before you ask for a quote

You will get more accurate and more comparable quotes if you can share:

• The problem you want to solve, and how you know it is a problem.
• The workflows you think are in scope, described as user tasks.
• The roles that use them, and how their access differs.
• Screenshots, a recording or access to the current product.
• Any evidence you have: support themes, analytics, customer feedback.
• Your front-end stack, and whether you have a component library.
• Who will build the design, and when.
• Your timeline, budget range and any fixed dates.

The copyable project brief in our scoping guide is one way to put this together. If you are not yet sure what the problem is, start with a review rather than a redesign. SaaS UX audits: what to review and what you should get back explains what that involves.