Web app development · B2B SaaS
Web app design and development for B2B SaaS
The short answer
Web app work for a B2B product covers the surface where customers spend real working hours: dense data, multiple roles, integrations, and the internal dashboard your own team runs on. It ships continuously, so the scoping question is what belongs in the first release, not what the product eventually becomes.
Your customers live in the web app for hours at a time, at a desk, with a keyboard. That's what makes changing it risky, and it's also why the parts that annoy them every day are the ones nobody ever gets around to.
What the web app is for, and what it isn't
Most B2B products end up with two surfaces, and the split isn't about parity. The web app is where the long work happens: a queue of records, a comparison, an investigation, a report that leaves the building. The phone covers a few jobs that happen away from a desk.
What decides it is rarely the feature itself. It's how long the session lasts, how much has to be visible at once, and whether the person has both hands free. A job that runs forty minutes and needs three things on screen at once is a web job however often it gets asked for on a phone.
It matters for scoping because requests arrive the other way round. A customer asks for an app, and the honest answer is usually that two of the six things they listed belong on a phone and the rest belong in a browser they already have open.
| The job | Web app | Phone | What decides it |
|---|---|---|---|
| Working through a queue of records | The main reason it exists | No | Volume. Forty rows, a filter and an action on a selection need width and a keyboard |
| Comparing two records side by side | Yes | No | Screen area. A phone can only offer this by asking you to remember the first record |
| Configuring roles, billing and connections | Yes | Rarely worth building | Consequence. Rare, careful work that needs its explanation next to it |
| Investigating a support case | Yes | No | Breadth. The answer needs a record, an audit trail and a setting open at once |
| Building a report and sending it out | Yes | No | Output. The result leaves your product for a spreadsheet or a board pack |
| Approving a single item | Works, seldom the fastest route | Better here | Time to decision. A minute of work with no supporting detail doesn't need a desk |
| Capturing something as it happens on site | No | Yes | Location. The record gets created where the work is, or it gets typed up later |
| Checking one number between meetings | Yes | Yes | Session length. Ten seconds of reading is the honest overlap between the two |
The research that has to happen before the interface
Most of the expensive corrections in a web app trace back to a question that was answerable in week one and got answered in month six instead. The order below matters as an order, because each answer narrows the next one.
None of it needs a designer. These are six answers your own database, your own team and your customers' documentation already hold.
1. Name the record everything else hangs off
Every B2B web app has one object the rest of the product decorates: an account, a case, a shipment, a study. Write down what it is, the states it moves through, and who's allowed to create one. Permissions, tables, exports and the admin tool all resolve against that answer.
2. Get the real shape of an account
From your own database rather than the sales deck: how many people sit inside your largest account, how many distinct roles they actually use, and whether anybody belongs to two accounts at once. That answer decides the permission model, and the permission model is the piece you can't change cheaply afterwards.
3. Pull the row counts instead of estimating them
Ask how many records your heaviest account holds today, and what that number was a year ago. Table layout, pagination, filtering, search and export all hang off it. A table designed against a demo account with forty rows meets a real one with forty thousand about a month after launch.
4. Find out what your own team does by hand
Before anyone designs a customer-facing screen, spend a morning with support, operations and finance. Ask which answers they retrieve manually, which spreadsheets exist because the internal tool doesn't produce them, and what they escalate to engineering. That list is usually the cheapest work available and it never reaches a roadmap unaided.
5. Inventory every system the product has to talk to
For each one, get the authentication model, the rate limits and a real payload rather than the marketing page. Then write down what a customer notices on the day it stops. That's the part of an estimate that's usually missing, and it's rarely the part that was difficult to build.
6. Decide which views have to be a link
Which filtered states get pasted to a colleague, which ones get bookmarked, and which ones get opened straight from a ticket rather than navigated to. That decides what belongs in the URL, and URL structure is awkward to change once customers have saved it. It's the last question before layout starts.
Roles and permissions are architecture, not a screen
In a B2B web app, almost nothing is visible to everyone. There's an account owner, people who can see billing, people who can see other people's records, and eventually a customer who wants their own custom role.
That model has to be decided before the interface, because retrofitting it isn't a feature, it's a rewrite of every query in the product. The questions worth settling on day one are whether permissions attach to a person or to a workspace, whether a person can belong to more than one account, and what an administrator can see about their own users.
Two more arrive later and are cheaper to answer early. One is what happens when a customer wants a role you don't offer, which turns permissions from a fixed list in the code into data somebody can edit. The other is single sign-on, because the account that asks for it is usually your largest one, and it changes how identity works rather than adding a login button.
Get all of that roughly right early and the next three years of features are cheap. Get it wrong and every new screen pays a tax.
Density is the interface
The web app is where people do the version of the job that takes an hour, so the primary object is usually a table with more rows than fit. Everything around that table is what makes it usable: filters that persist, saved views, sorting that survives a refresh, bulk actions, an export that produces what a person actually needs rather than a dump of the schema.
The browser gives you things a phone can't, and most B2B web apps use almost none of them. Behaviour that survives being opened in four tabs at once, because that's how people who live in your product actually work. Text you can select and paste into the ticket you're writing about it. A right-click that opens a record in a new tab instead of doing nothing.
Width is the other thing the browser hands you, and a lot of B2B apps spend it on whitespace borrowed from a marketing site. The screens people live in usually want more than one pane: a list beside the record it opens, a filter rail that stays put, a detail panel that doesn't lose your place in the list behind it. That's what keeps the back button out of the workflow.
Keyboard operability has a return that rarely gets counted. WCAG 2.2, a W3C recommendation since October 2023, makes keyboard operation a Level A criterion, the lowest of its three conformance levels. A product you can't drive from the keyboard misses the easiest bar the standard sets, and fixing that is the same work that makes your heaviest users faster.
None of it is glamorous, and all of it is what a customer means when they say your product feels fast.
The internal dashboard is a product too
Every B2B product has a second application behind it, the one support, operations and finance use to run the business. It gets built in a hurry, it never gets designed, and it's where a surprising share of your team's week goes.
When it's bad the cost isn't visible as a bug. It shows up as ops teams rebuilding the answer in spreadsheets, two numbers for the same thing, and support escalating anything they can't see. When it's decent, the customer-facing product gets better too, because the people closest to customers stop spending their time on retrieval.
Two rules make it safe to treat as a real product rather than a back door. Every action taken on a customer's data is attributable to a named person, and anything destructive is recoverable. Support looking at an account is normal. Support looking at an account with no record of who looked is a conversation you don't want to have with your largest customer.
When we rebuilt a market-research platform for healthcare providers, the internal dashboard for surveys, users and referrals was in scope from the start rather than a request that arrived after launch. Market research isn't SaaS, and the industry isn't what carries over. What does is that the tool the operations team used every day got designed as part of the product rather than assembled out of whatever the build left behind. That's the part we'd repeat.
Integrations are where the estimate goes wrong
Connecting to a CRM, a billing provider or a customer's own system is rarely hard on the happy path. The work is everywhere else: rate limits, partial failures, a field that's optional in the documentation and mandatory in practice, and the sync that stops overnight without telling anyone.
So the useful scoping question isn't how long the integration takes. It's what happens once it's been failing quietly since Tuesday. Who gets told, and how. Whether the records that never landed can be replayed without creating a second copy of everything. Whether one of your own people can put it right without a data cleanup and a week of apologies.
Idempotency is the cheap insurance here. If every write to the other system carries a key you can safely repeat, recovery is a replay rather than an investigation. Deciding that after the first outage means a reconciliation nobody planned for, and an estimate that priced only the happy path is the most common reason a build's second half looks nothing like its first.
Shipping alongside an in-house engineering team
Two arrangements work. We design and specify, your engineers implement, and we stay available through the build. Or we take a defined surface and ship it ourselves while your team keeps its own roadmap moving.
Where we're writing the code, it lands in your repository, under your branch conventions, through your review process, and it's your pipeline that has to go green before anything ships. That's worth settling before the first pull request rather than during it, along with who carries the pager for that surface once it's live and what a rollback looks like on a Friday afternoon.
The first two weeks are worth planning deliberately. Read access, a walk through the parts of the codebase that bite, then something small and real shipped end to end through your pipeline before the substantial work starts. A trivial change that reaches production tells you more about where the friction is than a week of onboarding calls.
Then name a reviewer, and a second one for when the first is away. If our pull requests sit three days behind the busiest person on your team, the arrangement costs you more than it returns, and that's the failure nobody writes down in advance.
Worth knowing before you start
Add keyboard shortcuts for the two actions your heaviest users repeat all day, then tell them the shortcuts exist. Discoverability is the part usually skipped.
Open your busiest screen at the narrowest laptop width your customers actually use. If a pane disappears there, most of your users are losing the layout the screen was designed around.
Ship the first release to one real account you can phone before you ship it to everyone. Not a beta programme, one customer whose reaction you can hear rather than read.
Related work
Further reading
Common questions
Either, and what decides it is where your team's attention is worth more this quarter rather than what either side is capable of. If your engineers are the only people who understand the part being changed, we design and specify and stay available while they build it. If they're mid-way through something they shouldn't be pulled off, we take a defined surface and ship it ourselves.
Extend, unless there's a specific reason not to. A rewrite means a long stretch where nothing visible improves and every existing behaviour has to be rediscovered. It's sometimes correct, and it should be argued for on evidence rather than assumed because the code is unfamiliar.
By scoping a defined first release rather than the whole product. A release you can describe precisely is one a changing roadmap can move around, because everyone can see what moving it costs. A release described as a theme is one where every quarter's change lands as an argument about what was meant.
We treat it as part of the same product rather than a leftover, which usually means a role inside it rather than a second application. It gets the same permission model, the same components and the same attention to error states, and anything your team does to a customer's data carries an audit trail.
As part of the build rather than a pass at the end, because retrofitting focus order through a product people already use touches every screen. A visible focus indicator, contrast, and states that don't depend on colour alone are most of it. The dense screens are where it takes real attention, since a table with an action menu in every row is where focus order usually falls apart.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.