That Thing You Built Isn't a Portal — Here's How to Build One

Part 3 of a series on the dos, don'ts, and dangers of vibe coding.

In the first article of this series, I complained about vibe-coded "portals" — customer-facing apps hosted on the internet with a thin veil of authentication, wired directly into the backend system that holds everything. I called that a fake portal and moved on. A few readers fairly asked: fine, so what does a real one look like?

That's this article. And I want to say up front who it's for. Some of the people building these things are developers who aren't very good. But a lot of them were never developers at all — they just picked up some genuinely powerful vibe coding tools, and the tools were happy to build whatever was asked. This is for both groups, and especially for the business owner who's paying either one.

A portal is a hole, not a door

The definition of a portal varies, but here's the thing it is not: it is not merely "somebody has web access into my system." A portal is a hole that lets you see through into something. It was never meant to be a thing that stands completely open.

The danger when people vibe code a portal is that they build a direct connection from the outside into the inside of their system. Now you're one hack away from someone having full access to everything. And you've given yourself a genuinely hard job, because you can't just block everyone — you're deliberately providing access to a bunch of people who should have it. So the server has to decide who gets in. Which means the server needs to be secure, the rules need to be secure, and everyone touching it needs to understand them. That's a lot of moving components, all of them load-bearing, all of them written by an AI in an afternoon.

Start with less data, not more security

Here's the move almost everyone gets backwards. The first question isn't "how do I protect all this data?" It's "why is all this data here?"

A portal should hold only the subset of data required to run the portal — not a copy of your database, not every aspect of your business. Say your customers are checking order status. You don't need credit cards in there. You don't need accounts receivable. You certainly don't need your HR database. You need a user ID, an order ID, and maybe a few extra bits of information. That's it. That filtering has to happen before anything else, because data that isn't there can't be stolen. Every table you leave out is a security feature that costs nothing and never has a bug.

Ask the elves the compromise question

I keep using this example, so here it is again: forget that it's an AI. Imagine you've got a crew of magical elves building this thing for you. What would you tell them?

Security first — and specifically: assume your application is compromised. Assume the server you deployed it on is compromised. Now what? What do you wish you had done? Whatever the answer is, that's the instruction. Go do that now, while it's cheap, instead of wishing for it later.

That question sounds paranoid until you follow where it leads, because it leads somewhere concrete.

The server that has nothing to steal

In a lot of our platform deployments, the front-end server — the thing exposed to the internet, the thing most likely to get hacked — has no access to the data at all. If you made off with that server, if you owned it completely, you wouldn't get anything beyond what was in flight, because it's the user's own authentication that brings access to the user's own data. The server never held the keys.

The pattern goes like this. The database and the documents live in a security platform — Firebase is an excellent model of this, and there are others; I'm not selling anyone's platform. Each user's documents are encoded with that user's identity, so the platform itself arbitrates who sees what. The exposed server has no control over that security and no standing access to that data.

And then the part people miss: data flows in one direction. The system on the inside — the one holding the full database, the one that knows the security and has the right to change things — pushes the portal's subset outward into the platform. Nothing on the outside can send data in, because there's no inbound path to send it through. The outside world reads what was deliberately placed within reach, and that's the entire relationship.

Now replay the compromise question. Somebody hacks the front-end server and takes the whole thing. What did they get? They really didn't get anything. That's not luck. That's the design answering the question you asked before you started.

You will not out-code the hackers

Let me be blunt about the alternative, which is what most vibe-coded portals do: writing your own access control logic. Unless it's being done on a serious security framework, just coding it yourself — or having the AI code it for you — is not going to beat the hackers today. It just won't happen. This isn't an insult to anyone's prompting skills. It's the same reason you don't vibe code your own encryption.

So before any application code exists, pick the platform. Ask what the most common, current, battle-tested frameworks are, and build on something widely used and actively maintained — alive, updated, with thousands of eyes on it. If it's public-facing, that's something like Firebase or Auth0. If it's internal, protection can be as simple as an identity-aware proxy or token-based access. The point isn't the brand. The point is that arbitrating access to data is a solved problem, solved by people who do only that, and your portal should be a thin layer of your logic on top of their years of getting attacked and patching.

Then — and this is the discipline part — build the security first, with nothing in it. Prove it out. Test it from a different session, as a different user, before a single piece of real data goes in. Security bolted on afterward, the "hey AI, go put security around this" move, is the same approach we've spent decades lamenting in human software development. It didn't produce good results when people did it, and the AI doing it faster doesn't change the outcome.

Audit the rules with a stranger

Suppose you've done all this. Platform chosen, rules written, data minimized. How do you know it's right?

Here's a place where AI genuinely shines — as the auditor, not just the author. When the rules are done, I take them to a different AI, in a fresh conversation, deliberately outside the chat that wrote them, and I ask it to describe what the rules do. Then I ask pointed questions. What can a guest user access? Is this specific thing allowed or not? What are the unexpected results? Does anything here match security anti-patterns you've seen?

The fresh session matters because of a simple truth: it's easy to catch something when it screams that it's broken. It's hard to know something is broken because something isn't there. The AI that wrote the rules shares your blind spots — it built the thing, so it sees what was intended. A stranger only sees what's written, and omissions are precisely what strangers are good at noticing.

And when the auditor finds a hole, resist the urge to patch that one line and move on. Security bugs are sometimes an oops, but often they grow out of a mistaken idea about how something works — and a mistaken idea rarely expresses itself in exactly one place. So I take the entire finding back to the original process: here's what we built, here's what the audit found, given this line of thinking, what else follows? Fixing the symptom is quick. Handing back the reasoning gives the system a chance to find the disease.

This is also why you keep records of why things are configured the way they are — the intentions, not just the rules. I'll say more about intentions in the prototype article, but they matter double here: a security rule whose purpose nobody remembers is a rule somebody will eventually "simplify."

The risk-reward sentence

As always, this comes down to the evaluation you already make about everything else in your business. If losing this data genuinely wouldn't matter — it's public anyway, there's nothing sensitive — then maybe most of this conversation doesn't apply to you, and a quick vibe-coded page is fine. That's a legitimate answer, arrived at honestly.

But if the data does matter, then the checklist is short and none of it is optional: only the data the portal needs, on a proven security platform chosen before coding started, with the exposed server holding nothing, data pushed one way from the inside, security built and tested empty before anything real went in, and the rules audited by a fresh set of eyes — silicon or otherwise — that you asked hard questions.

If whoever built your portal can't show you those things — not tell you, show you — then what you have isn't a portal. It's a door someone left open, and you're paying for the privilege of hoping nobody walks through it.