The login screen worked. The data was already in the browser.

On 16 October 2026, MyBroadband reported that an internal dashboard used by Bootlegger, the Cape Town-founded coffee franchise, had been exposing names and contact details linked to 132 of its stores, along with some of the business’s performance and financial data. The dashboard had a login screen. It just wasn’t protecting anything.

Nobody needed sophisticated tools to find it. According to MyBroadband, current employees had posted photos of their laptop screens on Instagram with the dashboard’s address visible. Somebody looked it up, curious programmers did the rest, and an anonymous poster disclosed it on the MyBroadband forums and Reddit. The app was taken down after MyBroadband asked the company for comment. Neither Bootlegger nor its CEO had responded by the time the article was published.

The report links the dashboard to vibe coding, based on the CEO’s own public posts about building internal software with AI tools. I want to be clear on one thing: building your own tools with AI is not the mistake. I’ve built a few myself. The mistake is what happened next.

What actually went wrong

When someone opened the dashboard’s address, the app sent the data to the browser along with the login page. The login form appeared on screen, but the information it was supposed to guard was already sitting in the page source, readable by anyone who right-clicked and chose “View page source”.

Think of it as a shop with a locked front door and the stock piled up on the pavement outside. The lock works perfectly. It’s just protecting the wrong thing.

Why a working login fools everyone

Ask an AI coding tool for “a dashboard with a login screen” and that’s exactly what you get: a dashboard, and a login screen. Whether the server refuses to send any data until it knows who’s asking is a separate question, and unless someone asks it, nobody does.

From the outside, the safe version and the leaky version look identical. The login works. The dashboard looks finished. The only difference is what the browser receives behind the scenes, and that’s the part nobody checks.

It’s the same pattern behind this year’s bigger international incidents, from Lovable-built apps shipping with their database rules switched off to Moltbook’s wide-open production database. Different tools, same gap. It’s also one I keep running into in the vibe-coded apps I look at: the app works, so everyone assumes it’s safe.

The five-minute test

If you, or someone in your business, has built an internal tool with AI, this is worth doing today. It needs nothing but a browser:

POPIA doesn’t care how the app was built

Names and contact details of identifiable people are personal information under POPIA. Section 19 requires appropriate, reasonable technical and organisational measures to protect it. Section 22 requires the responsible party to notify the Information Regulator and the people affected “as soon as reasonably possible” when there are reasonable grounds to believe their information has been accessed by someone unauthorised.

Neither section makes an exception for internal tools, side projects or apps built over a weekend.

Vibe coding is here to stay, and it should be. Building a genuinely useful tool in a few weeks is a real advantage. But the moment real company or personal data goes in, someone needs to check what the app hands out, and to whom.

I’m putting together a practical minimum checklist for vibe-coded apps, with the free tools to run it. Get in touch and I’ll send it to you when it’s ready. And if you’d rather have someone who didn’t build the app take a look before it goes live, that’s exactly the kind of fixed-scope review I run for clients.

References