Skip to content
Web & SaaS5 min read

Website, Web App or SaaS Platform: Which One Do You Need?

By Luis Pambid, Founder of YenkoDev

"We need a website" can mean three very different things. One is a few pages that tell people who you are. One is software your customers log into. One is a product you sell to other businesses by subscription. They look alike in a browser, but they take very different amounts of time and money to build, and very different amounts of care to keep running.

We build all three (Web & SaaS Development is one of our services), so read this as an explanation from an interested party. It's written to help you work out which one you need before you talk to anyone, us included.

The three things people call a website

A website tells people about your business and gets them to take a step: call, book, buy or send a message. It's mostly the same for every visitor. A café's site, a law firm's site, a landing page for one offer. Its job is to load fast, look trustworthy and be found on Google.

A web app is software that runs in the browser. Users log in, and each one sees their own things: their orders, their bookings, their records. A customer portal, a booking system, an internal tool your staff use every day. Its job is to do the work correctly, for every user, every time.

A SaaS platform (software as a service) is a web app you sell. Other businesses sign up, pay every month, and each one gets its own private space inside the same software. Its job is everything a web app does, plus billing, plans, and keeping each customer's data strictly apart from every other customer's.

An online store sits between the first two. It's a website that takes payments, with accounts and order history added on top.

What changes as you move down the list

Each step adds real work, and it helps to know where that work is.

Accounts. The moment users log in, you need sign-up, sign-in, password resets, and rules about who can see what. Getting this wrong is one of the most common ways private data leaks.

Data that matters. A website's content changes when you edit it. A web app's data changes every minute and belongs to your users. It needs a properly designed database, backups that are tested, and a plan for what happens when something goes wrong.

Payments. Taking money means a payment provider, receipts, refunds and failed cards. For subscriptions it also means plan changes and cancellations. In some regions it means local payment methods and instalment plans as well.

Keeping customers apart. In a SaaS platform, one business must never see another business's data. This has to be designed in from the first day. It is very hard to add later.

Admin tools. Someone on your side will need to look up a user, fix a record or issue a refund without calling a developer. Those screens are real work, and they're easy to forget in a quote.

None of this means you should avoid a web app or a SaaS. It means a quote that treats them like a website is either missing something, or planning to surprise you later.

Questions that decide which one you need

If you're not sure which one you need, these questions usually settle it:

  1. Does each visitor need to see something different? If not, it's a website. If yes, it's a web app.
  2. Will people pay you inside it? If they pay once, you need a store or a checkout. If they pay every month, you need subscription billing.
  3. Will other businesses use it as their own? If yes, it's a SaaS platform, and keeping their data apart is the first design decision.
  4. Who will change it after launch? If your team needs to edit pages or products without a developer, that has to be built in.
  5. Does it need to work like an app on a phone? Many web apps can, without the app stores. Our post on whether you need a mobile app covers when a real app is worth it.

What every one of them needs

Whatever you build, a few things should be true from the start, not added later:

  • Speed. A slow site loses visitors before they read a word, and Google ranks it lower. Speed is cheapest to build in and most expensive to fix afterwards.
  • The basics of being found. Clear page titles and descriptions, a site Google can read, and pages that answer the questions your customers actually search for.
  • Security. Up-to-date software, passwords and keys kept out of the code, and logins handled properly.
  • Ownership in your name. Your domain, your hosting account, your code and your data should all belong to you. If a developer holds them, you don't fully own your business online. We wrote about what happens when that goes wrong in getting your code and domain back.

Build the first version small

The most expensive way to build a web app or a SaaS is to build everything you can imagine before anyone has used it. The cheaper way is to decide what the first version must do for real users, build that well, and let real use decide what comes second.

That isn't cutting corners. Accounts, security and the data design should be done properly from the start, because they are hard to change later. What waits is the extras: the second report, the extra user role, the connection to a tool nobody has asked for yet.

Where to start this week

Before you talk to any developer, write one page:

  • Who will use it, and what is the one thing each kind of user must be able to do?
  • Will anyone log in? Will anyone pay?
  • Which tools does it need to connect to, if any?
  • Is there a date you're working to, and why that date?

That page answers the website, web app or SaaS question for you, and it's the most useful thing you can hand to whoever builds it. A good developer will ask you about everything on it. If someone quotes you without asking, that tells you something too.

Know what you need to build?

A few lines is enough: what it should do, who will use it, and any date you're working to. Every brief is read by a senior engineer, the same person who would do the work.

//Keep Reading

We use Google Analytics cookies to understand how the site is used. If you decline, we won't set them. We'll still remember your choice, and basic traffic and performance measurement runs either way. See our Privacy Policy.