The label is a symptom, not a decision
A lot of software goes wrong in the first meeting, before anyone writes a line of code, because the project gets a name too early. Someone says “we need an app” and six weeks later the team is scoping an app, when what the business needed was a dashboard and a better contact form.
The category should be the last thing you decide, not the first. Work out who the user is, what they are trying to do, and how often they will do it. The label falls out of those three answers.
Choose a website when the goal is trust
A website is the right answer when the job is to explain, be found, prove credibility and collect enquiries. It is not a lesser option — for most businesses it is the highest-return piece of software they own, because it is the one thing every prospect touches.
Signs you picked wrong: users are logging in. If people need accounts, saved state or personalised data, you have a web app wearing a website’s clothes, and the content management system will fight you for the next two years.
Choose a dashboard when the goal is visibility
A dashboard is right when the data already exists but nobody can see status, progress, problems or priorities without opening four systems. The output is a decision made faster, not a new capability.
Signs you picked wrong: people want to change things from inside it. The moment users need to update records, upload files or trigger actions, you are building a web app, and read-only architecture will not stretch to cover it.
If your current dashboard is a spreadsheet, start with from spreadsheet to internal dashboard, which covers exactly when that switch is worth making.
Choose a web app when users need to do something
A web app is right when people need accounts, forms, uploads, approvals, saved records, calculations or repeat actions. This is the broadest category and the one most business software actually falls into, including most things people call “a portal”.
Signs you picked wrong: you have exactly one customer and they are you. If the only users are your own staff, you are building an internal tool, and you can drop a large amount of onboarding, billing and self-service work you would otherwise pay for.
Choose SaaS only when you are ready to run a product business
SaaS is not a technical choice, it is a business model. Serving many customers from one system means accounts and permissions, billing and dunning, onboarding, support, uptime commitments, data isolation, analytics, and a roadmap that never ends. The screens are the small part.
Signs you picked wrong: you have not yet found the second customer with the same problem. Building SaaS for one client is a bespoke system with an unnecessary billing module attached. Build it for them properly, then generalise once a second and third customer confirm the shape.
What people ask for most and need least
Native mobile apps. They come up in almost every early conversation and are right in a specific set of cases: offline use, camera, GPS or sensor access, push notifications people actually want, and daily or near-daily use.
Outside those cases a mobile-friendly web app does the same job without two codebases, two review processes and two release cycles. The honest test is frequency. If a user opens it once a month, it will not survive on their home screen, and an app you have to remind people to install is a distribution problem you have created for yourself.
Budget for running it, not just building it
Every category above has a second number nobody asks about in the first meeting: what it costs to keep alive. Hosting, domains and certificates. Third-party services that price per user or per call. Security updates. Somebody to answer “it is not working” on a Tuesday morning.
A marketing site’s running cost is close to nothing. A SaaS platform’s is a permanent line in the budget, and the projects that stall are usually the ones that funded the build and not the year after it. Our pricing page sets out the bands, and we are happy to be blunt about which one a given idea belongs in.
Common questions
Do I need a mobile app or a website?
Almost always a website first. A mobile app is worth it when users need offline access, camera or sensor hardware, or open the thing several times a week. If people will use it monthly, a mobile-friendly web app does the job at a fraction of the cost and with no app store review.
What is the difference between a dashboard and a SaaS platform?
A dashboard shows your own team information they already have access to. A SaaS platform serves many separate customers, which means accounts, permissions, billing, onboarding, support and data isolation. The visible screens can look similar; the work underneath is an order of magnitude apart.
How much does each one cost?
As a rough UK guide: a strong marketing site is the cheapest, a prototype or proof of concept starts from £2,800, a rapid MVP from £2,995, a branded MVP from £9,000, and a production SaaS platform from £28,000. The jumps are mostly about accounts, permissions and support obligations.
Can we start with one and grow into another?
Yes, and it is usually the right plan — if the first one is built with that in mind. An internal dashboard can become a customer portal, and a portal can become SaaS. What does not convert cheaply is a marketing site pretending to be an application.
What if we genuinely do not know?
Then the answer is a prototype, not a platform. Build the smallest thing that puts the core idea in front of real users, and let their behaviour choose the category for you. That is what an idea validation or proof-of-concept engagement is for.
Related guides
- How to scope a prototype — what to build first once you know the category
- From spreadsheet to internal dashboard — the most common starting point
- Digital twin or dashboard? — the same decision for operational and spatial data
- Pricing — what each band costs to build