You Can Sell a Pre-Launch Safety Check for Local Booking Apps

Apps are built quickly, but important checks remain

Imagine building an app with booking, member management, and payment features using an AI app-building tool. A working interface is not the same thing as customer data being safely separated.

Security researchers Matt Palmer and Kody Low reviewed 1,645 public apps built with Lovable in 2025. They reported that 170 projects, or about 10.3%, had no customer-level data access rules or had configured them incorrectly. That is roughly one in ten apps in the sample. The key question was whether a public access key could be used to view another customer’s data.

The researchers said they could read about 500 email addresses in one app and, in a follow-up review, alter payment status to paid. However, the United States National Vulnerability Database includes the supplier’s objection. The supplier’s position is that this was a configuration issue created by individual app operators, not a single flaw in Lovable itself.

In 2026, Lovable also announced an incident in which build conversations and source code in public projects were visible to other logged-in users who knew the link. The affected period ran from February 3 to April 20, and the company said it fixed the issue within two hours of receiving a report. Private projects were not affected, but the habit of pasting external-service access keys or real customer data into build conversations also became something to check.

Small businesses are not exempt. In South Korea, the Personal Information Protection Commission and the Korea Internet & Security Agency reported 307 personal-data breach notifications in 2024: 171 caused by hacking and 91 by work-related mistakes. Small and medium-sized businesses accounted for 60% of the 203 notifications from private companies. Pre-launch configuration checks are therefore not only for large services.

Narrow it to one Pilates booking app in Bupyeong District

Consider a hypothetical case. Kim runs a Pilates studio with seven employees in Bupyeong District, Incheon. The studio takes bookings through KakaoTalk, a Korean messaging service, records remaining class passes in a ledger, and checks whether payments arrived through internet banking. The same member names and phone numbers are copied across chat windows, schedules, and the ledger.

Kim builds a member booking app using an AI app-building tool. Members view the timetable and book sessions, instructors mark attendance, and Kim manages class passes and payment status. The screens work, but it is hard to know whether instructors can download every member’s phone number or whether one member can alter an address in a URL and view another member’s bookings.

This is where a local pre-launch checking service comes in. The reviewer receives one test account each for the owner, instructor, and member, then logs in with fake member data. They check, in order, whether another member’s bookings can be viewed or changed, whether an administrator screen can be accessed directly, whether a member list can be downloaded, whether access keys are exposed, whether former employees still have accounts, and whether project conversations are public.

Payment needs a separate review. Check whether the studio app sends card-number entry to a payment-service provider’s payment screen rather than collecting card numbers directly, and whether ordinary users can change a payment amount or completion status. Sending card information to a payment-service provider does not automatically protect member names, phone numbers, or order records.

Instead of a difficult report, present the results in three groups. Put access to another member’s data, administrator access, and exposed secret access keys in the group that blocks launch. Put unnecessary data collection and old accounts in the group to fix after launch. For each issue, include the screen where it appeared, the steps to reproduce it, the setting that needs to change, and the date it was checked again.

After the review, Kim does not just hear that the app is vaguely safe. Kim knows what must be fixed before launch. Kim can also ask an outsourced developer not to “improve security,” but to “stop instructor accounts from downloading the member list.” When the same test passes after a fix, that item is complete.

Some work still requires people. Deciding which data each member should see requires listening to how the studio actually operates, and fixing discovered issues requires someone who can work with the app-building tool or development work. A simple review service should not promise to solve every attack or legal obligation.

When you narrow the area and industry, this manual work becomes a product. Pilates studios in Bupyeong District tend to share the same roles—owner, instructor, and member—and the same data structure of bookings, class passes, and attendance. That makes the review sequence reusable. A first product could include a 30-minute workflow review, a 90-minute test, and a one-page result delivered the next day, with completion defined as the three roles being unable to view one another’s data.

Elsewhere, audits are sold with a narrow scope

In the United States, Airdev audits apps built specifically with Bubble, rather than every kind of app-building tool. Its listed prices are USD 500 for a small app, USD 1,000 for a medium-sized marketplace app, and USD 1,500 for a large subscription app. It reviews customer-data exposure settings and screens and workflows.

This turns a security assessment from a large consulting engagement into outsourced review with a defined scope. Airdev does not disclose how many issues are fixed after an audit, but its approach of separating scope and price by app-building tool and app size is useful for a local service.

In the United Kingdom, Vibe Code Audit targets non-developers who build apps with AI app-building tools such as Cursor, Lovable, and Replit. It lists an audit of up to 10 integration points at GBP 297 with a three-business-day turnaround, a full audit of up to 25 points at GBP 997 with a seven-business-day turnaround, and a product including fixes at GBP 2,997 with a 10-to-12-business-day turnaround.

The company says it has audited more than 50 apps. Its customer examples include cases where a logged-in user could view another user’s data and where storage was completely open, but these are seller-published examples and need separate verification. Still, a market already exists for buying a defined pre-launch review with a set delivery time and output.

Four things you can build locally now

1. Booking app launch check

• Service: Check whether booking, member, and class-pass data are separated across owner, staff, and customer accounts, then report the result on one page.
• User: Owners of Pilates and yoga studios in Bupyeong District that built their own booking apps with AI app-building tools.
• Why now: App building has become faster, but small businesses can struggle to find someone to inspect an app just before launch.
• First screen: Let users select the app URL, app-building tool, personal data collected, and user roles, then press “Request a check.”

2. Staff-by-staff personal-data permission cleanup

• Service: Map the member information each employee can see and the actions they can take, then identify unnecessary permissions.
• User: Local fitness facilities where desk staff and part-time instructors work together and share administrator accounts.
• Why now: Problems may appear first in an existing administrator screen or a former employee’s account, rather than in a new app.
• First screen: Beside each employee name, let users check permissions for member lookup, phone-number viewing, payment changes, and member-list downloads.

3. Local outsourced-app handover inspection

• Service: Before accepting a finished outsourced booking or ordering app, check administrator accounts, access keys, customer data, and backup permissions.
• User: Owners of side-dish shops and small restaurants that hired a local development company or freelancer to build a takeaway-ordering app.
• Why now: If they check only that the screens are complete and pay the bill, they may discover account-control and data-ownership problems later.
• First screen: Enter the contract end date and the list of accounts received. The screen shows items not yet received and outsourced accounts that are still active.

4. Risk alert before taking payments

• Service: Before receiving a first paid payment, review the payment screen, amount changes, refund permissions, and the scope of member-information storage in sequence.
• User: Local craft workshops and small experience classes that have accepted only free bookings and are starting prepaid classes.
• Why now: Once a business starts taking customer payments, it is harder to remove test data and change the underlying structure.
• First screen: Ask three questions: “Who receives the card number?”, “Who can change payment completion?”, and “Who has refund permission?”

What to check today

Call three Pilates studios or craft workshops in Bupyeong District for 10 minutes each. Ask only whether they share administrator accounts with staff and whether they have ever tested that other customers’ data cannot be seen. If two of the three do not know the answer, and one of them is willing to review the screen with you, a local pre-launch checking service may be worth testing.

Why this matters where you are

You can check whether small booking businesses in your area share administrator accounts or have ever tested role-based access to customer data. The tools, payment providers, and local legal obligations may differ from the examples here. The practical opportunity is to turn a repeatable check for one type of business into a clearly scoped service before it launches an app.