The most expensive software decisions are made before any code exists: building a mobile app when a good website would have done, building custom when an off-the-shelf product existed, or building a website when the business actually needed a system. This guide sets out the options plainly and gives you a way to choose.
01The four options, in plain terms
- Website: pages people read. Marketing sites, documentation, catalogues. Content changes often; the logic rarely does. Should be fast, searchable and cheap to run.
- Web app: a tool people use in the browser, with accounts, data and workflows — a dashboard, a booking system, a portal. Works on every device without an app store, updates instantly for everyone.
- Mobile app: installed on the phone. Earns its place when it needs the device — camera, offline use, push notifications, background location — or when daily habitual use justifies the install.
- Custom software: a system built around your specific process, often integrating with what you already run (ERP, CRM, plant systems). Chosen when no product fits and the process is a real advantage worth encoding.
02How to choose
Answer these in order. The first one that fits usually decides it.
- Does an existing product do this well? If yes, and the process is not your competitive advantage, buy it. Custom software for a commodity process costs more and does less.
- Does it need the device? Camera, offline, notifications, sensors. If not, a web app reaches every device at a fraction of the cost and skips the app stores entirely.
- Is it mostly read, or mostly done? Reading points to a website; doing points to a web app.
- Will people use it daily and habitually? That is the strongest case for a native app; occasional use is a strong case against one.
- Does it have to integrate deeply with internal systems? That tilts towards custom software, and towards a partner who has done such integrations before.
03The mistakes that cost the most
- Building the app first. An app is a commitment to two platforms, store reviews and ongoing updates. Most products should prove themselves as a web app first.
- Treating the website as a brochure. It is usually the highest-traffic thing you own; it deserves speed, search visibility and measurement.
- Customising a product until it is custom software without the benefits of either.
- Ignoring the running costs: hosting, security updates, dependency upgrades, monitoring. Software is a thing you keep, not a thing you finish.
- Not owning the code, the domain, the hosting account or the data. Whatever is built, the accounts should be in your name.
04What to ask a development partner
- Which of the four would you build, and why not the cheaper one?
- What will this cost to run and maintain each year after launch?
- Who owns the code, and can another team take it over?
- How will it be tested for security before launch?
- How will we know, after launch, whether it is working — what is measured?
- What is the smallest version that proves the idea?
05A sensible default
Start with a fast website if people need to find and read. Build a web app if they need to do. Add a mobile app only when the device or the habit demands it. Build custom only where the process is yours and worth owning. Keep every account in your name and measure from day one.
In short
- Buy where a product fits and the process isn't your advantage; build where it is.
- A web app reaches every device without an app store; build native only when the device or daily habit demands it.
- Software is kept, not finished — budget for running it.
- Own the code, domain, hosting and data from the start.
Questions
Can a website become a web app later?
Yes, and that is often the right path: launch the site, add accounts and tools where people show they need them.
Is a progressive web app a substitute for a mobile app?
For many products, yes. It installs to the home screen, works offline to a degree and sends notifications on most platforms. It is not a substitute where you need deep device access or app-store distribution.
How long does a web app take to build?
It depends entirely on scope. The useful question is what the smallest version that proves the idea looks like, and building that first.
Sounds like your problem?
Tell us about it. We'll say honestly whether the swarm can help, and what it would take.
More guides