Website vs software: when do you need both?.

The line between website and software

A website presents and persuades: pages, proof, enquiry paths. Software executes: logins, accounts, workflows, data that changes state. The line is crossed the moment a user expects the site to remember them or a process to complete without a human forwarding emails.

Common crossing points in B2B: trade portals with account pricing, partner platforms, client document exchange, quoting and configuration tools, booking and scheduling, compliance workflows and dashboards. Quartix's partner platform and Universal Gas's dual-market enquiry routing both live on this line.

The practical difference is what breaks when it goes wrong. If a marketing page is wrong, a visitor is misinformed and you fix the copy. If software is wrong, a customer's data is wrong, and fixing it means finding every record the fault touched. That asymmetry is why software costs more per screen: the same visual work sits on top of testing, error handling, permissions and an audit trail that a brochure page never needs.

Is a login always software?

Effectively yes. The moment there are accounts, there are passwords to reset, permissions to enforce, sessions to expire, personal data to protect and a support burden when someone cannot get in. A gated PDF behind a form is not a login; a place customers expect to return to and find their own things is.

This is where a lot of budget gets lost. "Just add a client area" sounds like a page and is a system, and the gap between those two estimates is where the difficult conversation happens in month two. If someone quotes a login as a small extra on a marketing build, ask what happens when a user forgets their password, when an employee leaves, and when a customer asks for their data to be deleted.

What about calculators, configurators and quote tools?

These sit on the line and go either way. A pricing calculator that does arithmetic in the browser and shows a number is a website feature. One that saves the result, emails a quote, feeds the CRM and lets a salesperson pick it up is software, because there is now state that has to be right.

The useful question is whether anything is remembered. If the whole interaction dies when the tab closes, you are still on the website side of the line and should build it there — cheaply, quickly, and without a database.

Why the seam between agencies fails

The standard failure: a brand agency designs screens a development shop then quotes triple for, or a dev shop builds workflows wrapped in an interface buyers do not trust. Each blames the other, and the business pays for the translation layer in both money and months.

The fix is structural, not contractual: have the same senior people design the marketing site and build the software. That is Web Hero's wedge. Rudo-style design agencies stop at the marketing site; Dapper-style marketing agencies stop at campaigns; we design the site and ship the software behind it.

What makes the seam so expensive is that neither side is behaving badly. The design agency produced beautiful screens without knowing that one of them implies a permissions model. The development shop priced honestly against what it was handed. The cost of the misunderstanding is real, nobody is at fault, and there is no contract that recovers it — which is precisely why it has to be prevented structurally rather than argued about afterwards.

What does the handoff failure actually cost?

Two things, and the second is worse. The obvious cost is rework: screens redesigned to fit what is buildable, or engineering effort spent implementing something visually specified that a five-minute conversation would have simplified. The hidden cost is time, because each round trip crosses a company boundary and takes days rather than minutes.

The compounding version is a project where the marketing site and the product end up feeling like different companies. The buyer is persuaded by one experience, signs, logs in, and meets another. That gap does not show up in any project budget, but it shows up in churn.

How to phase it without overbuilding

Build the website first with software-grade structure: real data modelling, component systems and analytics. Then add software where measured demand appears, on the same stack. This is how a £4,500 site grows into a portal without a rebuild.

Overbuilding is the opposite risk: shipping a portal nobody asked for. The test is a named user with a weekly pain, stated in their words. No named user, no build.

"Software-grade structure" is doing specific work in phase one, not a slogan. It means content modelled as data rather than typed into pages, a component system rather than one-off layouts, and analytics installed at launch instead of six months later. None of it is visible on the finished site, and all of it is the difference between adding a portal and starting again.

• Phase 1: marketing site with structured data and measurement (from £4,500)
• Phase 2: the first workflow with a named user and a weekly pain (scoped from £18,000)
• Phase 3: integrations that remove manual steps, priced after technical discovery

Can we build the software first and the website later?

Sometimes, and it is the right order when the product is the business — when customers arrive by referral or sales and the website is a formality. Building a marketing site for a product that does not exist yet means writing promises you may not keep.

For most B2B companies the reverse is true, because the website is the thing currently producing pipeline and the software serves customers you already have. Fix the machine that brings people in before building the one that serves them better, unless the service problem is what is losing them.

Do we need both on the same technology stack?

It is not mandatory, but it is a large saving when it happens. Shared components mean the portal inherits the design system rather than reimplementing it, shared infrastructure means one deployment story, and shared people mean nobody has to be briefed twice.

The version that hurts is a marketing site on one platform and a product on a completely different one, maintained by different teams. Every change to the brand has to be made twice, and the second one is always late.

Signals you are ready for the software phase

Spreadsheets emailed weekly between you and customers, password-protected PDF dances, manual rekeying between systems, or sales answering identical pricing questions daily. Each is a workflow asking to run through the site. Bring one to a call and we will tell you honestly whether it is a £6,000 integration or a £25,000 product.

The strongest signal is when someone in your business has already built a workaround. A shared spreadsheet with colour-coded tabs, a folder structure with a naming convention only two people understand, a recurring calendar reminder to send an export — these are unpaid software, built by whoever felt the pain most, and they are the clearest possible specification for what to build properly.

The counter-signal is worth stating too. If the only argument for a portal is that competitors have one, or that it would look impressive in a pitch, the project has no named user and will be used by nobody. Portals with no weekly pain behind them get built, launched, praised internally and quietly abandoned within a year.