Product design
B2B & SaaS Product Design
Design for the software your customers log into: ordering platforms, dashboards, portals and internal tools.
What I take on
Six kinds of work, one underlying problem
Every one of these comes down to the same thing: the software has to fit a process that already exists, and the people using it did not choose it.
New product surfaces
A first version that has to ship and be usable, with the scope argued down to what is genuinely load-bearing.
Legacy portal rebuilds
Modernising software people depend on daily, without the week-one productivity cliff that kills trust in the project.
Dashboards and reporting
Screens that answer a question rather than displaying every metric the database can produce.
Ordering and distribution
Order entry, pricing, stock and fulfilment, where the real competition is a chat thread at nine at night.
Internal tools
The software your own staff cannot avoid, which gets the least design attention and returns the most.
Design plus front-end build
On smaller teams I ship what I design, so nothing is lost translating a file into a working screen.
How the work runs
Structure before surface.
Always in that order.
The first two stages decide whether
the last two are worth building.
Four stages / eight to twelve weeks
Stage / 01
Discovery, one to two weeks. Watching people use what exists, mapping the real process including the spreadsheets beside it, and agreeing what success is measured in.
Stage / 02
Structure, two to three weeks. Flows, states and the ugly cases first: empty, error, partial, and far too much data. Visual design waits until this survives contact with reality.
Stage / 03
Interface, two to three weeks. High fidelity screens for every state, the component decisions that make the rest of the product cheaper to build, and a spec engineers can work from.
Stage / 04
Build, or build support. Either I build the front end, or I stay close to the engineers who do, because the last ten percent is where designs quietly get compromised.
The difference
Software people cannot walk away from
Consumer products are judged on whether a new user understands them. B2B software is judged on whether an experienced user can still hit their numbers on a Tuesday afternoon.
That inverts almost every design instinct, and it is why the work looks like this:
- Edge cases are not rare, they are attached to your largest accounts
- The workarounds people built are unwritten requirements
- A cleaner screen that is three seconds slower is a downgrade
- Permissions and roles decide as much as layout does
What it costs
Ranges, not a menu
Working 2026 numbers for hiring me directly, without an agency or marketplace in between.
Product audit$1,500 to $4,000
One workflow or feature$3,000 to $8,000
Full product surface or portal rebuild$10,000 to $30,000
Design plus front-end buildAdd 40 to 60%
Monthly retainer$3,500 to $9,000
What moves these numbers, and how to compare two quotes that differ by a factor of ten, is in what a UI/UX designer costs.
Common questions
Before you get in touch
How much does B2B SaaS product design cost?
A product audit runs $1,500 to $4,000. One workflow or feature is $3,000 to $8,000. A full product surface or a portal rebuild is $10,000 to $30,000, and adding the front-end build is roughly 40 to 60 percent on top. Full rate context is in what a UI/UX designer costs.
How long does B2B product design take?
Discovery is one to two weeks, structure two to three, interface two to three. A defined workflow is therefore five to eight weeks. A multi-role product surface runs considerably longer, because the effort sits in states, roles and edge cases rather than in pages.
What is the difference between B2B and B2C product design?
B2C is judged on whether a new user understands the product. B2B is judged on whether an experienced user can still hit their numbers on a Tuesday afternoon. That inverts most instincts: edge cases attach to your largest accounts, the workarounds people built are unwritten requirements, and a cleaner screen that is three seconds slower is a downgrade.
Do you work with our existing engineering team?
Usually, and it is the common case. I design to whatever the team already uses and stay involved through build. On smaller teams without front-end capacity I build it myself.
Do you do design only, or the front-end build as well?
Both. On smaller teams I build what I design, which removes the handoff and the last ten percent where designs quietly get compromised. Where there is front-end capacity already, I stay close to the engineers doing it instead.
Do you need experience in our industry?
Not up front, but I need access to the people who have it. What transfers between industries is knowing which questions surface hidden complexity. What does not transfer is your pricing logic, and no designer should pretend otherwise on a first call.
How do timezones work?
I am on GMT+8: a full overlap with Singapore, Hong Kong and Perth, two to three hours from eastern Australia, and an early morning window with the US west coast. A fixed overlap window plus decisions in writing is enough.
Can we start small?
An audit is the usual way in. A few thousand dollars and a week or two tells you whether the problem is design, engineering, or a process nobody wrote down, and the third is more common than people expect.
The thinking behind it
Judgement, in writing
Tell me what the software does, who uses it, and what is going wrong.
I will tell you honestly whether it is a project I am right for. If it is not, I will usually know who is.