The slide nobody asked about
"Our product is SaaS, running on PaaS, on top of IaaS, with a multi-tenant architecture and full data isolation." After a vendor says that sentence, hands rarely go up. The owner nods, thinks it sounds professional, and signs the quote.
The problem surfaces three years later. You want a "returning-student auto-discount" rule and the vendor says it is a shared system so it cannot be done. You want to move your member list to a new platform and discover the export file contains no product images. You ask which server holds your customer list and nobody can answer.
These four terms belong in one article because they answer one question: which part of this system is yours, which part is the vendor's, and which part you share with strangers. Once you can see that line, you know what you are buying and what leaving will cost. These three layers are not vendor marketing either; they are defined in NIST SP 800-145, The NIST Definition of Cloud Computing.
IaaS: renting an empty lot and building yourself
In one line: the provider hands you machines, disks and network. Everything from the operating system up is yours.
Everyday analogy: renting a serviced empty lot with water and power already run to the boundary. The land is someone else's, but how many floors you build, what materials you use, whether you hire security, and when you rewire it are all your calls and your liability.
Real business case: a metal-fastener factory in Taichung moved its ERP and reporting server to the cloud. They chose IaaS because the ERP is over a decade old and pinned to a specific database version that no managed platform will install. An entry-level cloud instance runs from single-digit to a few tens of US dollars per month (see the official Amazon Lightsail pricing page) which looks cheap, but OS patching, daily backups, SSL renewal and firewall rules are nobody's job but yours. Google Cloud's official explainer states it plainly: under IaaS the customer remains responsible for the operating system, middleware, applications and data.
PaaS: renting a fully fitted office floor
In one line: the provider handles machines, OS and runtime. You only write the code and manage the data.
Everyday analogy: renting a whole floor that is already fitted out. Air conditioning, lifts, cleaning and security are the building's problem; you move desks in and start working. How you lay out the space and what sign you hang are still yours.
Real business case: a Taipei cram-school chain with six campuses needed a parent-facing enrolment and payment system. No off-the-shelf product handles their sibling-discount plus cross-campus timetable-clash rules, so the logic had to be built — but they did not want to employ someone to babysit servers. That is textbook PaaS. Pricing is usually usage or seat based; the official Vercel Pro plan documentation lists additional seats at US$20 per month each. You save the ops headcount; you pay by being tied to the stack that platform supports.
SaaS: renting one desk in a shared office
In one line: the whole application is ready to use. You manage accounts, permissions and your own content.
Everyday analogy: one desk in a co-working space. Chairs, printer, meeting rooms and coffee machine are all there and you can start tomorrow. You also cannot knock down a wall or decide when the coffee machine gets replaced.
Real business case: a two-person handmade-soap brand in Tainan launched an online store on an e-commerce SaaS in three weeks. Pricing for this tier is public: the entry plan on SHOPLINE Taiwan's official plan page is NT$40,000 billed annually, plus a one-off NT$5,000 activation fee, plus a 2% monthly GMV platform fee; the top tier is NT$88,000 per year at 1.5%. Internationally, the official Shopify pricing page lists Basic at US$39 per month. Fast to launch, no engineers needed — and your feature ceiling is whatever the platform ships.
Multi-tenant: one building, many units
In one line: one system serves many customers at once, and the design keeps their data apart.
Everyday analogy: an apartment block. Everyone shares the lift, water tank and risers, but each unit has its own lock. "How good is the soundproofing" and "could a key open the wrong door" are exactly what data isolation has to answer.
Real business case: a chain of aesthetic clinics adopting a booking system asked one question first: "are our treatment records in the same database as other clinics?" That is not pedantry, it is a question about the isolation model. The AWS whitepaper calls the shared-resource approach the pool model (cheap and efficient, but isolation is enforced in application logic), and the one-dedicated-stack-per-customer approach the silo model (expensive, no noisy neighbours); mixing both is the bridge model. Multi-tenant is not inherently unsafe, but it must come with an isolation design the vendor can articulate.
How the four fit together: a four-layer stack
Picture a diagram stacked bottom to top. The bottom layer is a grey data centre and servers, labelled "IaaS: you build it". Above it, an orange runtime and database layer labelled "PaaS: the building manages it". Above that, an amber complete application labelled "SaaS: sit down and use it". Across the top runs a dashed frame divided into cells, each with a padlock, labelled "Multi-tenant: separate units on the same floor". An arrow up the left side reads "less you can change"; an arrow down the right side reads "more you must maintain".
The point: IaaS, PaaS and SaaS are three vertical layers — the higher you join, the less you own and the less you can change. Multi-tenant is a horizontal cut — at any layer, if one set of resources serves several customers, it is multi-tenant. So "SaaS is always multi-tenant" is false (some SaaS vendors run dedicated environments for large accounts), and "self-built is always single-tenant" is false too (a system you build for franchisees has the same tenancy problem).
| Model | What you own | Time to launch | Cost to switch away |
| On-premise / self-hosted | Facility, hardware, OS, code, backups | Slowest | Low (you hold everything) |
| IaaS | Everything above the OS | Slow | Medium |
| PaaS | Code and data | Medium | Medium-high (stack lock-in) |
| SaaS | Accounts, permissions, content | Fastest | High (export format limits) |
Three common misconceptions
- One: SaaS is always cheaper. Revenue-share pricing scales linearly with your growth. Using the 2% GMV fee published on SHOPLINE's official page, a store doing NT$3,000,000 a month pays NT$60,000 a month in platform fees alone — NT$720,000 a year, far above the subscription itself. The bigger you get, the better self-built looks.
- Two: multi-tenant means my data is mixed in and visible to others. Sharing infrastructure is not sharing visibility. The real question is the isolation layer: separate database, separate schema, or a shared table with a tenant_id column doing all the work.
- Three: self-hosting is the safest option. Self-hosting makes OS patching, tested backup restores and certificate renewal your job. Most SMBs have nobody assigned to it, and the result is a server untouched for three years — riskier than a mature managed platform.
What this actually does to budget, timeline and risk
Budget: SaaS is a predictable subscription plus revenue share (as above: NT$40,000/year + NT$5,000 activation + 2% GMV). Self-built is a large upfront cost plus ongoing operations. Based on ScriptWalker's project experience, we estimate an SMB-grade custom order and membership system at roughly NT$250,000 to NT$600,000 and 6 to 12 weeks to build, then about NT$1,500 to NT$4,000 a month in hosting and 4 to 8 hours a month in maintenance.
Timeline: SaaS can go live in two to four weeks; PaaS custom builds usually start at six weeks; IaaS adds another one to two weeks of environment setup.
Risk — the one owners underestimate: exit cost. Do not only check how you get in. Shopify's official documentation states that product images are not included when you export products to CSV. So a brand with 1,200 SKUs that wants to migrate has to move the imagery separately — an estimated 16 to 24 hours of work for that single item. Put "what we can take with us" into the contract before you sign; it is far cheaper than negotiating it later.
Five questions to ask your vendor (copy these verbatim)
- ☐ "Is this SaaS, PaaS, or self-hosted? Who applies OS patches and runs the daily backups — you or us?"
- ☐ "At which layer is tenant isolation enforced? A database per customer, a schema per customer, or a shared table separated by a column?"
- ☐ "For feature A that I need: is it a settings toggle, custom development, or architecturally impossible? Please tell me which of the three."
- ☐ "If I switch vendors in three years, what data can I export, in what format? Does it include images, attachments and order history? Is there a fee?"
- ☐ "Beyond the subscription, which fees grow with my revenue or usage? Please model it at NT$1,000,000 and NT$5,000,000 monthly revenue."
FAQ
We are a five-person company using SaaS. Do we still need to understand PaaS and IaaS?
Yes, but only enough to ask good questions. You do not need to configure a server. You do need to tell the difference between "the platform genuinely cannot do this" and "the vendor would rather not". That distinction is often worth hundreds of thousands of NT dollars and six months of schedule.
In a multi-tenant system, can other merchants see my customer list?
Not if it is designed properly. Shared infrastructure and shared visibility are different things. Ask the vendor to describe the isolation layer and whether they hold a third-party security audit report. A vendor who cannot answer, or who only says "we are very secure", is a risk signal.
After a few years on SaaS, can I actually take my data with me?
Structured data — products, orders, members — usually exports to CSV. The surrounding assets often do not: product images, theme design, promotion configurations, and the URL structure you have built SEO on. Run a full export test in your first year rather than discovering the gaps on the day you leave.
When should we move from SaaS to a custom build?
When three signals appear together: revenue-share fees now exceed the annual all-in cost of building; the platform's limits are costing you revenue on a core workflow; and you need deep two-way integration with an internal ERP or POS. Any one signal alone rarely justifies the move.
Is white-label the same thing as SaaS?
No. SaaS describes how software is delivered; white-label describes whose name is on the door. A multi-tenant SaaS can let each customer apply their own logo, domain and colours — that is white-label — but underneath it is still the same shared system, and the customization ceiling does not rise because the sign changed.
Not sure which layer you belong in? Take 30 minutes
Choosing the wrong layer rarely hurts in year one. It hurts in year three, when you need a new capability and find the original architecture will not allow it. ScriptWalker offers a free 30-minute technical consultation. We look at your revenue scale, customization needs and data sensitivity, then tell you whether SaaS is fine, a PaaS custom build is warranted, or you should not touch the system at all. No pitch — just the options and their costs, laid out.
- Email：[email protected]
- Phone：0916-224-047
- LINE：@ufv9089p