Somebody asked me recently why the “website” they paid for costs a few hundred ringgit a year to keep alive, while the “website” their friend runs needs two people and a Slack channel that never sleeps. Same word, very different animals.
So this is me thinking out loud. Three levels, easiest to hardest: a static website, a single tenant web app, and a multi tenant web app. At each level I’ll ask the same two questions. What are you actually managing? And who, in the real world, ends up managing it? Because a gig worker, a 40-person SME, a large company with an IT department, and a lean startup all answer that differently. Then near the end I wander off into who should be holding the leash at the very top. Bear with me lah.
Static website
This site you’re reading is a static website. There is no server-side code, no database, no login. It’s a folder of .html files, one CSS file, one small JS file, and a git push. GitHub Pages copies the folder to the internet and that’s the whole deployment story. Optimisation FTW! 🥳
What am I actually managing here?
- The domain name. Renew it, point the DNS at the right place, don’t let it lapse and get sniped by a casino.
- Who can push. One GitHub account, mine. The entire access control model is “does Rudzainy have his laptop”.
- The content. Typos, broken links, images that go missing. That’s the whole incident list.
Blast radius of a mistake: a page looks wrong. Nobody’s data leaks because there is no data. Nobody gets locked out because there are no accounts. The worst-case scenario is embarrassment, and I have plenty of that already so no big deal. 😂
Now the perspectives, and this is where it gets interesting to me.
-
Gig worker / solo business owner
Honestly, this is the sweet spot. A one-page site, a Linktree, a WhatsApp button. The management cost is basically zero and that’s exactly right for someone whose “IT department” is themselves between customers. The trap is being upsold into something dynamic they don’t need.
-
Larger SME
Usually an agency built it, usually on WordPress, which technically stops being static the moment you install it (a database, a login page, 30 plugins, every one of them a door). They think they own a brochure. They actually own a small app with nobody watching it. Malam-malam kena hack, baru tahu.
-
Large company with a dedicated IT / tech department
The brand site sits on a proper CMS, behind a CDN, with a change approval process and a committee that argues about the hero image for three weeks. Over-engineered for a static site? Yes. But their blast radius is a press release, so the ceremony is kinda earned.
-
Lean startup on pre-built systems
Webflow, Framer, a Notion page with a custom domain. Shipped over a weekend, changed daily, nobody cares about the stack. Correct move. The landing page isn’t the product, so why spend engineering on it.
Notice something: at level one, control barely needs to exist. Whoever holds the login to the host and the domain registrar has all the control there is. Remember that, because it’s going to move.
Single tenant web app
Now add a database and a login page. One customer (maybe that customer is you), one deployment, one set of data. A CRM for one company. A booking system for one clinic. A Rails app on one server that does one job for one organisation. Most of the things I’ve built for other people live here.
The moment there are users, the list of things you’re managing grows teeth:
- Accounts. Passwords, resets, that one uncle who shares his login with the whole department.
- Roles. Who can see what, who can delete what. The UI hides buttons, but the server has to actually refuse.
- Backups. Not “we have backups” but “we have restored from a backup, on purpose, and it worked”.
- Uptime. The app is now in someone’s daily workflow. When it’s down, they can’t work, and they will call.
- Updates. Framework patches, dependency bumps, the database version going end-of-life on a Tuesday.
- Audit trail. Who changed this record and when. Nobody asks for this until the day everybody asks for it.
Blast radius: one organisation’s data, one organisation’s day. Bad, but contained. If I mess up the clinic’s booking system, the clinic next door is fine.
-
Gig worker / solo business owner
Congratulations, you are now Ops-Man™. Also Support-Man™. The 2am alert email is yours and yours alone. Most solo folks should not be here at all; they should be renting somebody else’s single tenant app (see level three, because that’s what SaaS is). If you do build your own, keep it boring. Boring is what you can fix at 2am half asleep.
-
Larger SME
This is home turf for the SME. One internal system, built by a vendor or that one guy in accounts who “knows computers”. Works great until that one guy resigns. Bus factor of one is the SME’s signature risk. The system isn’t the problem; the undocumented knowledge in one head is.
-
Large company with a dedicated IT / tech department
Staging environment, change requests, an on-call rota, a security review before anything touches production. Slow, yes. Annoying, yes. I’ve complained about rigid corporate structure before, and I stand by it. But at this level the ceremony is doing a real job: it spreads the knowledge and the responsibility across more than one person, which is precisely what the SME lacks.
-
Lean startup on pre-built systems
Rails or Next on a managed host, auth from a provider, payments from Stripe, email from a service, backups a checkbox on the dashboard. They rent every piece that isn’t the actual idea. Ops cost is a credit card. The cost shows up later as vendor lock-in, but later is a problem for a company that survived, which is the whole point.
Multi tenant web app
Same app, but now many customers share one deployment and, usually, one database. Every row has a tenant_id. Every query must filter by it. Every single one. Forget it once, and Syarikat A sees Syarikat B’s invoices. That’s not a bug, that’s a breach, and possibly a news article.
This is the hardest level, and not because the code is fancier. It’s because everything you were managing at level two is now multiplied by N and shared:
- Isolation. Data, files, background jobs, caches. All of it has to be scoped to the tenant, all the time.
- Noisy neighbours. One tenant runs a giant report and everybody else’s page gets slow.
- Migrations. A schema change runs for everyone at once. There is no “let’s try it on the small customer first” unless you build that.
- Per-tenant everything. Settings, branding, feature flags, the one customer who needs their own SSO.
- Billing and plans. Which tenant gets what, and what happens on the day they stop paying.
- Offboarding. A tenant leaves and wants their data exported, then deleted, and proof of the deletion. Try doing that cleanly from a shared database on a Friday.
- Data residency. Some tenants will ask where the bytes physically sit. Some regulators will ask louder.
Blast radius: everyone. One bad deploy, one leaked key, one missing where tenant_id = ?, and it’s every customer at the same time. Seems like a problem too big for one man lulz.
-
Gig worker / solo business owner
Here’s the twist: the solo person is almost never the landlord. They’re a tenant. Their invoicing, their bookings, their shop, all live inside somebody else’s multi tenant app. The management job flips from “keep it running” to “can I get my data out, and what happens if they shut down”. Most never ask until the shutdown email arrives.
-
Larger SME
Also mostly a tenant, but of five or ten SaaS tools that don’t talk to each other, so the real system is a spreadsheet stitching them together. What they should be managing is contracts, exports, and access (who still has the admin login after they resigned?). What they actually manage is the monthly subscription total, and only when finance complains.
-
Large company with a dedicated IT / tech department
Two flavours. Either they build internal multi tenant platforms (one HR system serving forty subsidiaries), or they are the customer who refuses the shared version and demands a “dedicated enterprise instance”, which is a single tenant deployment of a multi tenant app. Ironic, but rational: they are paying to shrink the blast radius back to level two.
-
Lean startup on pre-built systems
Multi tenant from day one, because that is the business model: one codebase, thousands of paying tenants. They lean on rented isolation: auth providers with organisation support, databases with row-level security built in, billing engines with plans and seats already modelled. Fast, and mostly safe, as long as somebody on the team actually understands what the rented pieces do and doesn’t just wire them up and pray. 😔
Where control lives
Look back at the three levels and follow where control had to be enforced:
Control keeps sinking one layer lower each time, closer to where the data actually lives, further from where the decisions get made. And every layer down, it gets harder to put in after the fact. Adding a login to a static site is a weekend. Adding proper tenant isolation to a multi tenant app that’s been live for three years is a rewrite that nobody wants to fund.
So who enforces the last row of that table? The one above the company?
MCMC as a digital government?
Bear with me. This is the part where I wander.
Strip away the apps, the tenants, the frameworks, and the internet at its core is just a bridge. A way for two people to talk more efficiently and effectively than the physical world allows. It hacks the limitation that you and I have to be in the same room, or wait for a letter, or pay for a long-distance call. Everything else, the shops, the banks, the SaaS, the memes, is stuff we’ve built on top of that one hack.
If that’s true, then the bridge is public infrastructure the way roads and water are. And right now in Malaysia the body looking after that bridge is MCMC, the Malaysian Communications and Multimedia Commission. A regulator. A commission under a ministry, one portfolio among many, with a budget and a mandate that was written when “multimedia” still meant CD-ROMs.
Meanwhile the thing it regulates is the layer every single one of the four perspectives above depends on. The gig worker who is a tenant of five foreign platforms. The SME whose customer list is in a shared database in a region they can’t name. The large company whose “dedicated instance” still phones home. The startup whose entire isolation story is rented from a vendor in another jurisdiction.
Now my hot take, kept short because that’s the only way I know how to do these:
MCMC should not be a commission.
It should be elevated into a dedicated digital government, with the same weight as a ministry that runs roads or health.
Not to censor the bridge. To keep it standing, keep it fair, and make sure the people on it can get off with their belongings.
What that would actually enforce, following the ladder from above: data export as a right, not a feature. Deletion with proof. Tenant isolation as a requirement for anyone hosting Malaysians’ data, audited, not self-declared. A local floor for where the data of a Malaysian tenant can sit. Basically the last row of that table, with teeth. PDPA gestures at some of this. A commission can write a guideline. A government can make it the default.
I sketched what the stack could look like in The Framework, and I’ve grumbled about the power imbalance in Users vs Corporations. This post is the missing middle bit: the infrastructure argument for why somebody above the companies has to hold the leash, because the companies’ incentive will always be to ship first and isolate later.
Yet to be concluded
So, three levels. Static: manage the login. Single tenant: manage the app. Multi tenant: manage the data layer, and pray your team never forgets one where. And above all three, a question I don’t think we’ve answered as a country yet.
I’ll probably come back and rework the MCMC bit once I’ve argued it with a few people. Or once someone tells me it’s already been proposed and I just didn’t gugel hard enough.
This blog post is still in progress. ^.^