Website, business software or custom platform: which scope fits?

"We need something built" covers three quite different purchases. A website presents the business and brings enquiries in. Business software runs an operation: orders, bookings, stock, jobs, invoices. A custom platform is a product in its own right, often with several kinds of user who pay or transact with each other. They share a technology stack and a development process, but they are scoped, priced, hosted and maintained differently, and asking for one when you need another is the most common reason a project drifts. This article is about recognising which one you are buying before anyone writes a proposal.

The three scopes in one view

Scope one: a website

A website's job is to explain what you do to someone who has never heard of you, prove you are real, and make the next step obvious. It holds content and enquiries and little else. The work is mostly in information design, writing, photography and the quality of the build: speed, accessibility, correct structured data, sensible forms. An online shop is still this scope when the catalogue is yours and the operation behind it (stock, fulfilment, returns) is handled by people and existing tools; it moves towards business software when the shop has to drive that operation.

Signs you are buying a website: the brief talks about pages, sections, the enquiry form and how the site should look; the people who will use the admin side are editors; the integrations are a mailing list, analytics and perhaps a payment provider for the shop. The things that go wrong are rarely technical. Content is late, decisions about tone and imagery stall, and the site launches with stand-in copy that is then forgotten. Scope the content production as a named workstream with an owner, and the build will go to plan.

The corporate website package and the online shop package describe this scope in their base, add-on and custom lists, and the matching services (company website development, online shop development) cover the custom end of it.

Scope two: business software

Business software exists to run something. The screens matter less than the rules: what a record can do, who can change it, what has to happen before it moves to the next state, and what the business sees as a result. A booking diary, a job-card system for a workshop, a treatment-plan tracker for a clinic, a wholesale ordering portal with customer-specific pricing: each is a workflow with records, roles and states, and the scope is a description of that workflow.

Signs you are buying business software: the brief contains the words "at the moment we do this on a spreadsheet", there is a list of people with different jobs, and the questions that come back in discovery are about edge cases ("what if the customer cancels after the deposit?"). The risk is that the rules are not written down anywhere. The person who runs the operation knows them, applies them inconsistently, and discovers the inconsistency only when the software applies them the same way every time. Discovery for this scope is a walk through the operation with that person, and the scope document is the list of rules that came out of it.

Business software is usually customised from a sector package when the operation is common, and built custom when the rules are unusual. Either way it is yours: it runs your operation, holds your records, and changes when your rules change. That last point is the part to plan for. Rule changes are the normal life of this scope, and a maintenance arrangement that covers them is part of the purchase, not an afterthought.

Scope three: a custom platform

A platform has more than one side. A marketplace has buyers and sellers. A booking platform has venues and the people who book them. A software product has subscribing customers who each run their own small operation inside it. The business that commissions the platform is often not the main user of it; it is the operator, and its job is onboarding the sides, keeping them honest and keeping the money moving correctly between them.

Signs you are buying a platform: the brief has at least two kinds of account that sign themselves up; money flows between parties, not only to you; there is a question of trust (reviews, verification, disputes) that the product has to answer; and the plan includes "phase two". The risks are specific. The second side is harder to recruit than the first, and the product has to be useful to the first side before the second exists. Payouts, commissions, refunds and disputes are where most of the complexity sits and where most of the underestimation happens. Operations after launch (support, moderation, release management) are a continuing cost that the business has to staff or buy.

Platforms are phased by nature. A first release that serves one city, one category or one side well, with the operator doing by hand what the software will later automate, is a better scope than a full marketplace on day one. The marketplace platform development service and the multi-vendor marketplace package are written around that phasing: what the first release contains, what is deferred, and what the operator does manually in between.

Questions that tell the scopes apart

1. Who logs in, and why? Editors only: a website. Your team with different roles: business software. Strangers who sign themselves up on more than one side: a platform.
2. What is the record that matters most? A page or an enquiry: website. An order, booking, job or case: business software. A transaction between two other parties: platform.
3. Where does money go? To you, for your goods or services: website or software. Through you, to someone else: platform.
4. What breaks if the system is down for a morning? Nothing operational: website. Your team's day: business software. Other people's businesses: platform.
5. What changes most often after launch? Content: website. Rules: business software. Features for a growing set of users: platform.

When the honest answer is "two of them"

Many businesses need a website and business software, and the mistake is to buy them as one project. A manufacturer needs a site that explains the range and a trade portal that lets account customers order at their prices; the site is a website, the portal is business software, and they share a login only if that is actually useful. A venue needs a site that sells the venue and a booking system that runs the enquiries; again, two scopes. Scoping them separately makes each one honest about what it has to do, allows them to be phased, and lets the website launch while the software is still in discovery. They can share a design system, a hosting arrangement and a developer without sharing a scope document.

Phased or single release?

A website is usually a single release with content updates afterwards. Business software is best released in phases that follow the operation: the record and its states first, then the screens for each role, then the integrations, then reporting. A platform is always phased, because its second side cannot be designed properly until the first side is real. The practical rule is that each phase should leave the business able to run on what has been delivered, even if some of it is done by hand. A phase that cannot be used until the next phase arrives is not a phase; it is a single release with extra meetings.

A labelled example

What to do with this

Answer the five questions for the thing you have in mind. If the answers point at more than one scope, say so in the brief: a developer who knows they are being asked for a website now and software later can propose both honestly. Then compare your answers to the package or service for that scope, and ask for a proposal with the brief attached. The scope you name is the scope you will be quoted for, and naming it correctly is most of the work.