Engineering Practice
Engineering Practice5 min read
B2B web application development: what makes it different, and how to build one that sells
A B2B web app is not a consumer app with a login. The buyer is not the user, the data belongs to someone else's company, and one enterprise deal can decide your architecture.
Working on something like this?
Get an estimateThe short version
- In B2B the person who buys is rarely the person who uses it, and your product has to satisfy both.
- Roles, permissions, and tenant isolation are core architecture, not features to add later.
- Enterprise buyers will ask about SSO, audit logs, and security before they ask about price.
- Integrations decide adoption. A B2B app that cannot connect to the customer's other systems stays a pilot.
Consumer apps compete on delight and volume. B2B web applications compete on fit, trust, and how little friction they add to someone's working day. The technology overlaps, but the design priorities are different enough that teams who treat the two as the same thing usually discover the gap during their first serious sales cycle.
This guide covers what is genuinely different about B2B web application development, what to build first, and how to choose a partner who has to live with the consequences of the decisions.
What makes B2B different
- The buyer is not the user. A procurement lead, a department head, and an end user all judge the product on different criteria. Your product has to pass all three.
- Accounts are organisations, not people. Everything hangs off a company: its users, its data, its billing, its settings.
- Fewer users, higher stakes. A hundred customers can be the whole business, so one bad outage or data issue is a relationship problem, not a bug report.
- Long, evidence-driven sales. Security questionnaires, integration requests, and custom asks arrive before the contract does.
- Workflows over pageviews. Success is measured in tasks completed and hours saved, not in sessions.
The architecture decisions that are expensive to change
1. Multi-tenancy
Every B2B product has to decide how one customer's data is separated from another's. Shared schema, schema per tenant, and database per tenant each trade cost against isolation. It is one of the few decisions that is genuinely painful to reverse, and the right time to make it is before an enterprise buyer asks. We cover the trade-offs in choosing a multi-tenant model.
2. Roles and permissions
“Admin” and “user” is rarely enough. Real customers want an owner, department managers, read-only auditors, external contractors, and sometimes per-record access. Model permissions as data (roles, scopes, resources) rather than as if statements scattered through the code, and enforce them in one place on the server.
3. Identity and single sign-on
Larger customers will want to sign in through their own identity provider using SAML or OpenID Connect, and to provision and remove users automatically. Retrofitting this is far harder than leaving room for it. Even if you launch with email and password, keep identity separate from the user's profile so a company can later bring its own.
4. Audit trails
Who changed what, and when. This is a sales requirement long before it is a compliance one, because it is how a customer's security team decides whether to trust you. Build it as an append-only record from the first write, not as a log added in year two.
Features B2B buyers expect
Integrations decide adoption
A B2B application rarely replaces everything a customer uses. It sits among a CRM, an ERP, accounting software, and a data warehouse, and the people using it will not re-key data between them for long. If your product cannot read from and write to those systems, it stays a pilot.
- Ship a documented public API early. Customers will build around it, and it forces clean boundaries inside your own code.
- Use webhooks for events. Polling does not scale and customers dislike it.
- Plan for reconciliation. When two systems disagree, someone has to decide which is right, and the product should make that visible.
- Prioritise by customer demand, not by logo count. Build the three integrations your pipeline keeps asking for.
Where the work is mostly joining existing systems, our system integration work is the closest match, and it is usually the highest-value layer in a B2B estate.
Security as a sales asset
Enterprise buyers send security questionnaires, and the answers shape whether the deal proceeds. You do not need every certification on day one, but you do need sound fundamentals and a clear story: encryption, access control, logging, backups, dependency hygiene, and an incident process. When a customer asks for formal assurance, SOC 2 readiness is usually the first framework, and it goes faster when the underlying habits already exist.
A sensible build order
1
Pick one buyer and one painful workflow
Not a platform. One role, one job, one measurable improvement: hours saved, errors removed, cycle time cut. Everything else waits.
2
Get the foundations right
Tenancy, permissions, identity, and audit trail. They are invisible in a demo and decisive in a security review.
3
Build the core workflow end to end
Including the unglamorous parts: import, error states, notifications, and the admin screens your own support team will live in.
4
Pilot with two or three real customers
Real data and real users. Treat the first deployments as research and expect to change the product.
5
Add integrations and reporting in order of demand
Let what customers actually ask for set the roadmap, and resist custom work that cannot become a standard feature.
If you are still validating the idea, scoping an MVP around that single workflow is almost always cheaper than building the full product first. When the foundations are proven and you are ready to scale a multi-customer product, a SaaS platform build is the next step.
Choosing the stack
The stack matters less than the team's fluency in it. Mainstream choices such as React or Next.js on the front end, a typed back end in Node.js, .NET or Python, and PostgreSQL for data are safe, hireable, and well supported. Choose what your team can maintain for five years, not what is fashionable this quarter.
What it costs
Cost follows scope: the number of user roles, integrations, and compliance requirements matter far more than the number of screens. An internal tool for one department is a very different project from a multi-tenant product sold to enterprises. Our breakdown of what custom software costs and what an MVP costs gives realistic ranges and the factors that move them. Budget for ownership too: running and evolving the product is a recurring cost, not a one-time one.
Choosing a B2B development partner
What to look for
- They ask about your buyer and your users before they discuss features
- They raise tenancy, permissions, and SSO unprompted
- They can show integration work, not only polished front ends
- They propose a narrow first release and a pilot, not a big-bang launch
- They explain how the product will be supported after launch
- You can speak to the engineers who will actually do the work
If you are weighing options, questions to ask a software development agency is a good checklist for the conversation, and staff augmentation versus a managed team helps you decide how to engage. When you are ready to talk specifics, get in touch and we will give you a straight read on scope and approach.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
It is the design and build of web software sold to or used by businesses rather than consumers. Typical examples are customer portals, SaaS platforms, workflow tools, dashboards, and ordering systems. The defining differences are organisation-level accounts, role-based permissions, integrations with customers' other systems, and a heavier emphasis on security and reliability.
In B2B the buyer is often not the user, accounts represent companies rather than individuals, and sales cycles involve security reviews and integration requests. Architecture reflects this: multi-tenancy, granular permissions, single sign-on, and audit trails matter far more than they do in most consumer products, and success is measured in workflow outcomes rather than engagement.
It depends on scope more than anything else. The number of user roles, integrations, and compliance requirements drive cost far more than the number of screens. A focused internal tool is a fraction of a multi-tenant product sold to enterprises. Budget as well for ongoing maintenance and support, which is a recurring cost after launch.
A narrow first release covering one workflow for one buyer is typically a matter of a few months. A full multi-tenant platform with integrations, SSO, and reporting takes longer. Starting with a scoped MVP and a pilot with a few real customers is usually the fastest route to a product people will pay for.
Most B2B buyers expect role-based access, single sign-on and multi-factor authentication, audit logs, data import and export, an API, reporting, flexible billing such as invoicing and purchase orders, and integrations with their existing tools. Several of these are requested in the first security questionnaires, so they are better built once, early, than added as one-off exceptions.
If you serve many customers from one product, almost always yes, because it keeps cost and operations manageable. The real decision is how isolated tenants are: a shared schema is cheapest, while schema-per-tenant or database-per-tenant gives stronger isolation for regulated or large customers. Decide deliberately before the first enterprise deal forces the question.
There is no single best stack. Mainstream, well-supported choices such as React or Next.js on the front end, a typed back end in Node.js, .NET, or Python, and PostgreSQL for data work well. Pick the stack your team can maintain and hire for over several years rather than the newest option.
Look for a partner who asks about your buyer and users first, raises tenancy, permissions, and SSO unprompted, and can show integration work. They should propose a narrow first release, explain post-launch support, and let you speak with the engineers doing the work. Be cautious of a fixed price before any discovery.