The 30-second decision
If you only have 30 seconds, here it is:
- Your customers find you on Google, look around, decide whether to call → you need a website.
- Your staff (or a closed group of clients) log in and do work — bookings, orders, records, dashboards → you need a web app.
- You want to sell access to a tool to many different businesses, each as a separate paying account → you need a SaaS.
Most projects only fit one of these. The wording founders use ("I want a platform where…") usually obscures which one is actually being described. Read on for the longer version.
What a website actually does
A website is your business's presence on the internet. The reader-traveller comes in, looks around, leaves with an impression. The site might invite them to call, to email, to book a meeting, to buy a product, or to subscribe to a newsletter — but the core verb is read. They're reading about you.
Things that are clearly websites: corporate brochure sites, restaurant and clinic sites, law firm and accounting firm sites, portfolio sites, marketing landing pages, single-product e-commerce stores up to a few dozen SKUs, blog/content sites, real estate listings (where listings are content not interactive search).
Typical features: home, about, services, work / portfolio, blog, contact form, basic e-commerce. May include a small member area for downloadable PDFs or member-only articles — that's still a website.
What a website doesn't do: it doesn't let users do work in any meaningful way. The moment "users log in to submit bookings, update records, run reports" is part of the brief, you've left website territory.
What a web app actually does
A web app is software you access in a browser instead of installing. The user comes in to do something — submit a request, manage records, view a dashboard, run a workflow. The verbs are active, not passive.
The defining quality of a web app vs a SaaS is the customer model. A web app typically serves one organisation — usually yours, or a single client of yours. There's no sign-up flow for the general public; user accounts are created by an admin.
Things that are clearly web apps: internal HR portals, custom CRMs for one team, booking engines for one business, member-only client portals, custom dashboards pulling from internal data, in-house inventory management, employee time tracking, vendor management systems.
Typical features: secure login, role-based access (admin vs staff vs maybe end-user), forms, lists, reports, integrations with other tools (accounting, payments, WhatsApp), email/SMS notifications, sometimes file uploads.
What a web app doesn't do: it doesn't serve multiple unrelated paying customers from different companies all at once with their data kept separate. Once that shape appears, you've crossed into SaaS.
What a SaaS actually does
A SaaS is a web app you sell access to — usually on a monthly or annual subscription — to many different organisations at once. Each customer (called a "tenant") gets their own account, their own users, their own data, their own settings, kept completely separate from every other customer.
Things that are clearly SaaS: any tool you'd recognise as "software you pay monthly for" — Slack, Notion, Calendly, Stripe, Mailchimp, Zoho, Storehub, Loyverse, Maxis Business solutions. The category covers an enormous range of products but they share the same shape: one product, many separately-paying customers, self-service signup.
What makes a SaaS structurally different from a web app is everything that supports having lots of paying tenants:
- Multi-tenant data architecture — tenant A can never see tenant B's data, by design
- Subscription billing — Stripe or similar, with plan changes, prorating, failed-card handling, dunning
- Self-service signup — new customers create accounts without you intervening
- Plan-based feature gating — Pro users see features Starter users don't
- Onboarding flow — new tenants get to "first value" quickly without a human walking them through
SaaS is the most expensive of the three because all of the above costs real money to build and operate. We cover the pricing decisions for a SaaS in detail in SaaS Pricing Models for Southeast Asian Founders.
The confusions that cost money
A few overlap patterns we see repeatedly with new clients.
"I want a website with a login area"
This is often a web app in disguise. If the login area is genuinely just "read members-only content", it's still a website. If users log in to do anything — submit forms that get processed, manage their own records, view personalised data — it's a small web app. The price gap is significant: misclassifying a small web app as a website usually means the developer underquotes, runs out of budget, and either ships something broken or asks for more money halfway through.
"I want a web app I can later turn into a SaaS"
The retrofit is one of the most expensive moves in software. Adding multi-tenancy, subscription billing, plan gating, and self-service signup to an existing single-tenant web app is roughly 60–80% of the cost of building the SaaS version from scratch. If SaaS is plausibly in the plan, design as multi-tenant from day one — it's only marginally more upfront, vastly cheaper later.
"I want a platform where customers can…"
The word "platform" is the warning sign. Founders use it to mean anything from a contact form to an Uber-scale marketplace. Before quoting, we always strip the word out of the brief and rewrite in plain English — "users submit X, system does Y, admin sees Z" — and the scope usually shrinks by 70%.
"It's just like Notion / Calendly / Stripe but for X"
Almost always larger than the founder expects. Notion, Calendly, and Stripe each had dozens of engineers iterating for years. The right framing isn't "build the whole thing" — it's "what's the smallest version that solves the first painful workflow, and what does our MVP look like for the next 100 users". We cover the MVP-scoping question in How Much Does a Custom Web App Cost in Malaysia?
Cost & timeline at a glance
The numbers below are our typical Malaysian SME quote ranges. Each project is unique, but the brackets are accurate for "well-scoped, reasonable expectations".
| Type | Typical cost (MYR) | Timeline | Ongoing cost |
|---|---|---|---|
| Website | RM 2,800 – RM 6,800 | 2 – 4 weeks | ~RM 0 – 200/month (hosting included yr 1) |
| Web App | RM 12,000 – RM 35,000+ | 4 – 10 weeks | ~RM 500 – 2,000/month (hosting + care plan) |
| SaaS | RM 25,000 – RM 80,000+ | 8 – 16 weeks | ~RM 1,500 – 5,000/month + service fees (Stripe, infra) |
The jump from website to web app is roughly 4–6× the cost. The jump from web app to SaaS is roughly 2× again. These are not arbitrary multipliers — they reflect the real work involved in adding authentication, multi-user permissions, integrations, and (for SaaS) tenant isolation and billing.
How they evolve over time
Most Malaysian SMEs we work with don't stay in one category forever. The common evolution paths:
Website → Website + member area. Most common. The marketing site stays, and a small members-only section gets added — downloadable resources, recorded webinars, a community space. Still a website at heart.
Website → Website + small web app. The business runs into a manual workflow that's now too painful to handle in spreadsheets and emails. A small web app gets added — usually on a subdomain like app.yourbusiness.my. The marketing site stays as the front door; the web app handles the operational work.
Web app → SaaS. The internal tool the company built for themselves turns out to be useful to similar businesses, and they start asking if they can pay to use it. This is one of the cleanest SaaS origin stories — but the transition still requires real engineering work to add multi-tenancy and billing.
Website + Web app → Brand consolidation. After a few years, the marketing site and the web app start to feel like two different products with confusing UX. A redesign brings them back under one consistent brand and shared component library, often with the web app gaining a polished marketing surface and the website gaining live data from the app.
7-question diagnostic
Answer these seven questions and the right category usually becomes obvious.
- Do users need to log in to use this? No → website. Yes → web app or SaaS.
- Will multiple unrelated companies pay to use this, each with their own data? Yes → SaaS. No → web app or website.
- Do users actively do work (submit, manage, process) inside the product? Yes → web app or SaaS. No → website.
- Does the product need different permission levels (admin / staff / customer)? Yes → web app or SaaS. No → website is probably enough.
- Does it integrate with payment, accounting, or POS systems? Yes → web app or SaaS. No → website is fine.
- Will customers self-serve signup without you talking to them first? Yes → SaaS. No → web app, or website with contact form.
- Are you charging recurring subscriptions to use the product? Yes → SaaS. No → web app or website.
If 3+ questions point to SaaS, you're building a SaaS. If 3+ point to web app and zero point to SaaS, web app. Everything else, website.
30 秒先决定
如果您只有 30 秒，就这样判断：
- 客户在 Google 找到您、看一看、决定要不要联系 → 您要的是网站。
- 您的员工（或一组固定客户）登录后做事——预订、订单、记录、数据看板 → 您要的是 Web App。
- 您要把工具的访问权卖给很多不同公司，每家各自有自己付费的账户 → 您要的是 SaaS。
大部分项目只清楚地属于其中一种。创始人用的措辞（"我要一个 platform 让……"）通常会模糊掉真正在描述的是哪一种。继续看下去会更清楚。
网站到底做什么
网站是您生意在网上的存在。读者像旅人一样进来、看一圈、带走印象后离开。网站可能邀请他们打电话、发邮件、预约会议、买产品、订阅通讯——但核心动词是"看"。他们在了解您。
明显属于网站的：企业宣传站、餐厅和诊所网站、律师楼和会计师楼网站、作品集网站、营销落地页、几十个 SKU 以内的单品电商、博客/内容网站、房地产挂牌站（挂牌是内容不是互动搜索）。
典型功能：首页、关于我们、服务、案例 / 作品、博客、联系表单、基础电商。可能含一个小型会员区让人下载 PDF 或看会员专属文章——这仍然是网站。
网站不做的事：它不让用户真正做事。一旦需求是"用户登录后提交预订、更新记录、跑报表"，您就跨出网站的范围了。
Web App 到底做什么
Web App 是在浏览器里用的软件，不用安装。用户进来是为了做某件事——提交请求、管理记录、看仪表板、跑工作流。动词是主动的，不是被动的。
Web App 跟 SaaS 最根本的差别在客户模式。Web App 一般服务一个组织——通常是您自己，或者您的某一个客户。没有公开的注册流程；用户账号由管理员创建。
明显属于 Web App 的：内部 HR 后台、单团队用的定制 CRM、单个业务用的预订引擎、客户专属门户、从内部数据抓取的定制仪表板、内部库存管理、员工考勤、供应商管理系统。
典型功能：安全登录、角色权限（管理员 vs 员工 vs 也许最终用户）、表单、列表、报表、跟其他工具的对接（会计、支付、WhatsApp）、邮件/短信通知、有时还有文件上传。
Web App 不做的事：它不会同时服务多个互不相关、来自不同公司的付费客户，并且各自数据彼此隔离。一旦出现这种形状，您就跨进 SaaS 范畴了。
SaaS 到底做什么
SaaS 就是您把"访问权"按月或按年订阅卖出去的 Web App——同时服务很多不同的机构。每个客户（叫"租户"）有自己的账号、自己的用户、自己的数据、自己的设置，跟其他所有客户完全分开。
明显属于 SaaS 的：任何您会形容为"按月付费的软件"——Slack、Notion、Calendly、Stripe、Mailchimp、Zoho、StoreHub、Loyverse、Maxis Business 的解决方案。这一类涵盖范围很大，但形状是一样的：一个产品、多个各自付费的客户、自助注册。
SaaS 跟 Web App 结构上的不同，全在那些支撑"有很多付费租户"的东西：
- 多租户数据架构——租户 A 永远看不到租户 B 的数据，从设计上就是这样
- 订阅计费——Stripe 或类似的，含套餐升降、按比例计费、卡失败处理、催款
- 自助注册——新客户自己创建账号，不需要您介入
- 按套餐解锁功能——Pro 用户看到的功能 Starter 用户看不到
- 引导流程——新租户能快速到达"第一个价值"，不需要真人手把手
SaaS 是三种里面最贵的，因为上面这些都要真金白银去开发和运营。SaaS 的定价决策我们在 东南亚 SaaS 创始人的定价模式指南 里详细讲过。
最常见的几个混淆
新客户身上反复出现的几个重叠模式。
"我要一个网站带登录区"
这个常常是 Web App 假扮成网站。如果登录区真的就是"看会员内容"，那还是网站。如果用户登录后要做任何事——提交表单后会被处理、管理自己的记录、看个性化数据——那就是小型 Web App。价钱差距很大：把小型 Web App 误归为网站，开发者通常会报价过低、预算用完，结果不是交付一个有问题的版本，就是中途要求加钱。
"我要做一个 Web App，以后能改成 SaaS"
"改造"是软件里最贵的动作之一。在已有的单租户 Web App 上加多租户、订阅计费、套餐解锁、自助注册，工作量大约是从头建 SaaS 版本的 60–80%。如果 SaaS 还在计划里，从第一天就按多租户设计——前期只多一点点，后期省非常多。
"我要一个 platform 让客户可以……"
"platform"这个词就是警示信号。创始人用它指任何东西——从联系表单到 Uber 规模的市场平台都有。报价之前，我们都会把这个词从需求里拿掉，用大白话重写——"用户提交 X，系统做 Y，管理员看 Z"——范围通常缩小 70%。
"就是 Notion / Calendly / Stripe 那样，但是针对 X"
几乎总是比创始人想象的大。Notion、Calendly、Stripe 每个都是几十个工程师迭代了好几年才有今天。正确的思路不是"把整个东西建出来"——而是"能解决第一个痛点工作流的最小版本是什么，下 100 个用户的 MVP 长什么样"。MVP 范围控制的问题，我们在 在马来西亚做一个定制 Web App 要多少钱？ 里有详细讨论。
成本和时间对比
下面的数字是我们给马来西亚中小企业的典型报价区间。每个项目都不一样，但这些区间对"范围清楚、期望合理"的项目是准确的。
| 类型 | 典型成本（令吉） | 时间 | 持续成本 |
|---|---|---|---|
| 网站 | RM 2,800 – RM 6,800 | 2 – 4 星期 | 约 RM 0 – 200/月（含第一年主机） |
| Web App | RM 12,000 – RM 35,000+ | 4 – 10 星期 | 约 RM 500 – 2,000/月（主机 + 护理计划） |
| SaaS | RM 25,000 – RM 80,000+ | 8 – 16 星期 | 约 RM 1,500 – 5,000/月 + 服务费（Stripe、基础设施） |
从网站跳到 Web App，成本大约是 4–6 倍。从 Web App 跳到 SaaS，又大约是 2 倍。这些倍数不是随便乘的——它们反映的是加上身份认证、多用户权限、各种对接、（SaaS 还要加）租户隔离和计费，实际工作量的差距。
它们随时间怎么演变
我们合作过的马来西亚中小企业大部分不会永远停在一个类别。常见的演变路径：
网站 → 网站 + 会员区。最常见。营销网站保留，加一个小型会员专区——下载资源、录播研讨会、社群空间。本质上还是网站。
网站 → 网站 + 小型 Web App。生意撞到一个手工流程，已经痛到不能再靠 Excel 和邮件解决。一个小型 Web App 加上来——通常放在子域名，例如 app.yourbusiness.my。营销站继续做前门；Web App 处理运营工作。
Web App → SaaS。公司给自己建的内部工具，结果对同行业其他公司也有用，他们开始问能不能付钱用。这是最干净的 SaaS 起源故事之一——但转型仍然需要真实的工程工作来加多租户和计费。
网站 + Web App → 品牌整合。几年后，营销站和 Web App 开始感觉像两个不同产品、UX 也乱。一次重新设计把它们带回到一个一致的品牌和共享组件库——通常 Web App 多了营销层的精致感，网站也多了来自 App 的实时数据。
7 题自诊清单
回答下面 7 题，正确类别通常就明显了。
- 用户需要登录才能用吗？不需要 → 网站。需要 → Web App 或 SaaS。
- 会有多个互不相关的公司付费使用，各自的数据分开吗？会 → SaaS。不会 → Web App 或网站。
- 用户会在产品里主动做事（提交、管理、处理）吗？会 → Web App 或 SaaS。不会 → 网站。
- 产品需要不同权限层级（管理员 / 员工 / 客户）吗？需要 → Web App 或 SaaS。不需要 → 网站够了。
- 要跟支付、会计、POS 系统对接吗？要 → Web App 或 SaaS。不要 → 网站可以。
- 客户会自助注册而不需要您先跟他们沟通吗？会 → SaaS。不会 → Web App，或者带联系表单的网站。
- 您会按周期订阅收费让客户用产品吗？会 → SaaS。不会 → Web App 或网站。
3 题以上指向 SaaS → 您要建的是 SaaS。3 题以上指向 Web App 而 0 题指向 SaaS → Web App。其他情况 → 网站。
Frequently asked questions常见问题
Can a website also have a login area for clients or members?网站可以带客户或会员登录区吗？
Yes — and the boundary between a website with a login area and a small web app is genuinely fuzzy. Our rule of thumb: if the logged-in area is mostly content the visitor reads (member-only articles, downloadable PDFs, account-status pages), it's still a website with a member area. If the logged-in area is where users actually do work — submit bookings, manage records, run reports — you're into web-app territory and the build/price/timeline shift accordingly.
可以——网站带登录区跟小型 Web App 的界线确实模糊。我们的经验法则是：如果登录区主要是访客"看"的内容（会员专属文章、可下载 PDF、账户状态页），那还是带会员区的网站。如果登录区是用户真正在"做事"——提交预订、管理记录、跑报表——您就进入 Web App 范畴了，开发/价钱/时间都跟着变。
What's the practical difference between a web app and a SaaS?Web App 和 SaaS 的实际差别是什么？
A web app serves one organisation — yours, or a single client's. A SaaS serves many separate paying customers (tenants) at once, with each tenant's data isolated from the others. The product itself can look almost identical from a user's point of view; the difference is on the inside: multi-tenant data architecture, subscription billing, plan-based feature gating, self-service signup. Building a web app and "turning it into a SaaS" later is one of the most expensive mistakes founders make — it's much cheaper to design as multi-tenant from day one if SaaS is the plan.
Web App 服务一个组织——您自己，或某一个客户。SaaS 同时服务多个分开付费的客户（租户），每个租户的数据彼此隔离。从用户角度看，产品本身可能几乎一样；差别在内部：多租户数据架构、订阅计费、按套餐解锁功能、自助注册。先建 Web App 再"改成 SaaS"是创业者最贵的错误之一——如果计划里有 SaaS，从第一天就按多租户设计便宜得多。
Can we start with a website and add a web app to it later?可以先建网站，以后再加 Web App 吗？
Yes, very common. Most Malaysian SMEs we work with start with a marketing website to be findable and credible, then add a web app 6–18 months later when they hit a specific operational bottleneck (manual booking process, scattered customer records, growing pile of spreadsheets). The web app can live on the same domain (e.g. /app/) or a subdomain (e.g. app.yourbusiness.my). Either works; subdomain is slightly cleaner for hosting and security. We design websites to be web-app-extendable rather than throwaway from day one.
可以，很常见。我们合作的马来西亚中小企业大部分先建营销网站让自己被找到、看起来可信，6 到 18 个月后撞到具体运营瓶颈（手工预订、客户记录散乱、Excel 越堆越多），再加 Web App。Web App 可以放在同一个域名下（例如 /app/）或子域名下（例如 app.yourbusiness.my）。两种都行；子域名在主机和安全上稍微干净一些。我们设计网站时就让它可以延伸到 Web App，不是一次性用完的设计。
Is an "online portal" for clients a website or a web app?给客户的"在线门户"算网站还是 Web App？
Almost always a web app, even if it's commonly called a "portal". The word portal implies users log in and do something — view their order history, submit a service request, upload documents, check invoices. All of that is web-app behaviour. If it's truly just "log in and read", you might get away with a website + member area, but in our experience the requirements quickly grow past that boundary within the first few months of use.
几乎总是 Web App，就算大家习惯叫它"门户（portal）"。"门户"这个词暗示用户登录后要做事——看订单历史、提交服务请求、上传文件、查发票。这些都是 Web App 的行为。如果真的就只是"登录看看"，可能用网站 + 会员区就够，但根据我们的经验，需求在开始用的几个月内就会很快超出那个边界。
Do I need separate websites for English and Chinese, or one bilingual site?英文和中文要分两个网站，还是一个双语站就好？
One bilingual site is almost always the right call. Two separate sites doubles your hosting cost, doubles your update workload, splits any SEO authority you build, and creates two places to keep in sync. A well-built bilingual site uses hreflang tags so Google serves the right language to the right user, lets visitors toggle languages, and shares the same backend infrastructure. The same logic applies to web apps and SaaS — multi-language built into one product, not a separate product per language.
一个双语站几乎总是对的选择。两个分开的站：主机成本翻倍、更新工作量翻倍、积累的 SEO 权重被分散、两边要保持同步。建得好的双语站用 hreflang 标签让 Google 给对的用户送对的语言、访客可以切换语言、共用同一套后端。Web App 和 SaaS 同样道理——多语言内建在一个产品里，不是一种语言一个产品。
What if we're not sure which we need?如果我们不确定到底要哪一种怎么办？
Talk it through with someone who's seen the patterns. Most founders we meet describe what they need in product-design language ("I want a platform where customers can…") when the underlying business problem is much smaller (or sometimes much larger) than the wording suggests. A 30-minute discovery call usually surfaces the real shape — and we'll tell you honestly if what you're describing is a website, a web app, a SaaS, or something a $20/month off-the-shelf tool already does.
跟见过这类模式的人聊一下。我们见到的创业者大部分用"产品设计语言"描述需求（"我要一个 platform 让客户可以……"），但底下的商业问题往往比措辞小得多（有时也大得多）。30 分钟的咨询会议通常就能看出真正的形状——我们也会老实告诉您：您描述的是网站、Web App、SaaS，还是其实有个每月 USD $20 的现成工具就能搞定。
