The pitch sounds the same in Dubai, Almaty, Warsaw and S\u00e3o Paulo. A friend who codes, a two-person studio fresh out of a bootcamp, or an energetic guy from Instagram says: “Why pay a subscription every month? I’ll build you your own booking system with AI. Three days, one flat fee, and it’s yours forever.”<\/p>\n
The uncomfortable part is that the pitch is honest. The system really will exist in three days. It really will work. For the first week.<\/p>\n
At Altegio we write code with AI every day: internal tools, integrations, reports. So we know both what these tools can do and where they stop. This article is not about “AI is bad”. It’s about what happens to your client base, your money and your reputation when an app nobody has read meets real clients, real payments and a real attacker.<\/p>\n
The term comes from Andrej Karpathy, one of the founders of OpenAI. He described a mode of working where you “forget that the code even exists”: you accept every change without looking, paste error messages back into the chat without understanding them. He also said what it’s good for: throwaway weekend projects.<\/p>\n
Simon Willison, one of the best-known programmers alive and a co-creator of the Django framework, put it more bluntly: vibe coding is building software with an AI without reviewing the code it writes. He also drew a line worth remembering. Not all AI-assisted programming is vibe coding. A professional uses AI too, but reads every line, tests it and can explain what it does. Willison’s rule: “I won’t commit any code to my repository if I couldn’t explain exactly what it does.”<\/p>\n
Here’s a simple test for anyone offering you “your own system”. Open any twenty lines of their code and ask them to explain what the lines do and what happens if someone types a quotation mark into the phone field instead of a number. If there’s no answer, you’re not buying a product. You’re buying a chat transcript.<\/p>\n
These aren’t our estimates. They come from companies whose job is finding holes in software.<\/p>\n
None of these figures depends on how talented your particular vibe coder is. They describe the tool.<\/p>\n
In January 2026 entrepreneur Matt Schlicht launched Moltbook, a social network built with AI. Within days, security researchers at Wiz found the entire production database exposed: tens of thousands of email addresses and private messages.<\/p>\n
This isn’t exotic. Missing authorization is the most common serious flaw found in scanned vibe-coded apps, and the reason is simple. As the Tacavar hardening checklist puts it: “Each prompt that generated the app optimized for what was in front of it. Nothing enforced a plan across prompts.” The appointment screen got built, the client screen got built, and the check “does this person actually have the right to see this list” never made it into any prompt.<\/p>\n
Now map that onto your business. Your database holds client phone numbers, visit history, before-and-after photos, health questionnaires if you do aesthetics or medicine, and payment amounts. Gabriel Bernadett-Shapiro of SentinelOne draws the line like this: “The moment that it touches other people’s personal data, then that’s when the standard changes,” even for a one-afternoon project.<\/p>\n
And here’s the part the vibe coder won’t bring up: the law doesn’t care who wrote the code. If the hole was left by an AI, the duty to report a breach applies just the same. Under GDPR that means 72 hours to notify the regulator and fines of up to 4% of annual turnover. Telling your clients that their phone numbers and photos are out there is also your job, not the contractor’s.<\/p>\n
The second most common finding in vibe-coded apps: unvalidated webhooks. A webhook is the address where outside services (your payment provider, a messenger, your website) send messages like “client paid” or “client booked”. If the app doesn’t check who sent the message, that address becomes an open door through which anyone can write to your database: create appointments, change prices, mark visits as paid.<\/p>\n
Third finding: data is checked only on the screen. The booking form won’t let you type text into a date field, but the server behind the form accepts whatever is sent to it directly. That is enough for a SQL injection. Boomberg, a vibe-coded site, carried one for months after launch, and its owner found out by accident.<\/p>\n
The fourth finding isn’t about security but about business logic. AI writes the happy path and skips the constraints you consider obvious: a promo code works once, a refund can’t exceed the payment, an eight-visit membership doesn’t become nine. Static analysis won’t catch this. Your first sharp client or your first sharp employee will.<\/p>\n
Willison warns about money specifically: vibe-coded apps calling paid APIs without limits have already cost developers thousands of dollars. The bot that answers clients through ChatGPT gets stuck in a loop and burns the month’s budget overnight. The Slash and Tacavar checklists make “caps on model calls and a daily budget” mandatory precisely because vibe-coded projects almost never have them.<\/p>\n
Your own payments are a separate story. If “your own system” takes deposits and prepayments, every hole from the previous section is a hole in your till.<\/p>\n
Jer Crane, founder of PocketOS, told The Verge how an AI coding agent he’d trusted with his code wiped the company’s production database entirely. It isn’t a one-off: a similar story with Replit’s agent deleting a startup’s production data made the rounds in summer 2025.<\/p>\n
Why it ends in disaster for vibe-coded projects is explained by the Slash checklist. A typical project lives in a single environment: the contractor tests changes directly on your live database. Backups with a tested restore procedure sit in the checklist under “should have, first sprint after launch”. In other words, at the moment you’ve paid and started working, they don’t exist.<\/p>\n
For comparison: in October 2026 one of our clients had an administrator quit. The account had been registered in his name. Before leaving he exported the client base and deleted most of the clients. The data and the access were restored, because the platform keeps backups, an activity log and has people whose job is restoring things. Who do you call to get your base back when it was wiped by a script written three months ago?<\/p>\n
Step zero of the Tacavar checklist is called “Control and Ownership”: who owns the repository, the cloud account, the domain, the database, the keys. The authors are blunt: fast builds end up scattered across personal accounts and forgotten registrars.<\/p>\n
In our own support channels it looks like this. A client connected a third-party integration built by a small team. Some time later they needed to change the address that went out in messages to clients. The team’s contact person stopped responding; their developer, in the words of our support team, “is just the technical guy” and won’t talk to clients. The internal thread ended with “basically, nobody knows anything,” and the service had to be pulled from our public catalog.<\/p>\n
Our commercial director, Anton Lutsevich, has a list of questions we ask any business that has decided to “do it all ourselves”: “Are they ready to support everything themselves now? Data security, data retention, continuous improvements, the human factor of a developer or team just disappearing. Someone will have to be paid either way, or they’ll be doing all of this themselves instead of growing the business.”<\/p>\n
While the app works, the question feels theoretical. It stops being theoretical at nine on a Saturday morning, when online booking won’t load and the only person who knows where the server password lives isn’t picking up.<\/p>\n
The most honest comment on this also comes from Anton, from an internal discussion of a two-location business that dropped its subscription and “built its own online booking”: “If it’s only online booking, then yes, it’s easier to leave, the coding pays off the same day. But the problems will definitely start when volumes grow and different types of operations appear, and someone will have to fix all of it (pay someone), and someone will have to train the staff on the product (pay again).”<\/p>\n
We know what breaks first from reviewing clients who left for “their own” system and came back. Home-built software doesn’t cover the whole operation: memberships, client debts, package deductions, group sessions, schedules across several locations. Manual spreadsheets and exports grow around it quickly and never add up to a clear picture. Online booking turns out not to be “a website with a calendar” but logic: who, with whom, on which membership, at which location, with what deposit.<\/p>\n
A beauty business in Chi\u0219in\u0103u left us saying they were “developing their own system”. Fifteen months later the owner came back and explained why: the system turned out to be inconvenient for clients and staff. A sports federation tried to handle group-class enrollment with its own website and came for ready-made logic for groups and memberships. A chain of 11 locations that had worked with us for eight years launched its own system, and our proposal to them was not to come back but to keep their development as a layer on top of the platform, because a full replacement “carries an unjustifiably high volume of permanent responsibility”.<\/p>\n
Tacavar describes the same dynamic in money: each month spent adding features on an unaudited foundation adds 20\u201330% to the eventual rebuild bill, because each feature deepens its dependency on the structure that will need untangling.<\/p>\n
One more thing that gets forgotten on purchase day. Mobile apps have to be rebuilt for every new iOS and Android release. WhatsApp and payment providers change their connection rules. Tax authorities change receipt requirements. On a platform, a team does this. In “your own system”, that same developer does it, if he’s still answering.<\/p>\n
The Slash checklist ends with a line worth rereading before you pay: “The first real incident \u2013 a failed payment, a data leak, an unexpected 500 error \u2013 exposes every gap.” At that point you have two options. Hire engineers to take apart code nobody has read (that’s the $50,000\u2013500,000 rescue), or admit that a year ago you bought not a system but a deferred invoice.<\/p>\n
Joe Procopio, an Inc. columnist and experienced founder, simply shut down his vibe-coded app after it was hacked and went back to running demos over Zoom. He had that option. A business with a live client base and a calendar full of tomorrow’s appointments doesn’t.<\/p>\n
Comparing a subscription with a one-off developer fee is misleading, because the subscription includes things you’ll have to buy separately with “your own system”. Here’s what usually isn’t part of “three days and a flat fee”:<\/p>\n
Our internal rule of thumb after reviewing these cases: at two locations, a home-built system never pays off; at ten locations it can make sense if you’re prepared to spend around $500 a month just on keeping it alive. That’s before the cost of the first serious incident.<\/p>\n
Ask them in writing. This is a condensed version of the professional checklists from Slash, Tacavar, Cyberlop and OWASP.<\/p>\n
If three or more questions have no answer, you’re looking at a prototype. Prototypes are useful. You just can’t put your client base and your till in one.<\/p>\n
It would be dishonest to end on fear. Willison and Karpathy are right: for one-off tasks, internal spreadsheets and quick experiments, AI-assisted development is the best thing to happen to small business in a decade. We work that way ourselves, and we watch our clients build their own reminder bots, their own analytics screens, their own industry-specific interfaces.<\/p>\n
The difference is in one thing: what it stands on. Our position, the same one we explained to that chain of 11 locations, goes like this. The platform remains the operational core: appointments, the client base and history, schedules, locations, access rights, notifications, backups, security and support. Everything that makes your business different from the one next door, you can build yourself on top of that core, through the API and AI assistant connections. That way you keep everything you’ve already built, without moving the cost and risk of running the base platform onto your own team.<\/p>\n
In other words, we’re not against your development. We’re against your client base and your till resting on code nobody has read.<\/p>\n
A prototype in three days isn’t a saving. It’s an invoice that arrives later, and it’s made out to you, not the contractor.<\/p>\n","protected":false},"excerpt":{"rendered":"
Someone offered to build your own booking system with AI in three days. What happens to your client base, payments and reputation in the following year, with numbers and real cases<\/p>\n","protected":false},"author":6,"featured_media":47681,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[830,158,313],"tags":[],"class_list":["post-47708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-biznes-uk","category-data-protection-uk"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t