Sample report · a demo app we built
Performance & Security Check and Fix: Sample Report on a Demo Booking App
Please read first. This report covers a demo app that bytecreo built for testing. It is not a real company, shop or customer. Every name and phone number in it is made up. We built in mistakes on purpose, the kind we often see in apps put together quickly with AI tools. Nothing was put online; all of the work happened on our own computer.
Written 2026-10-26 · bytecreo
At a glance
- On a phone, the main photo on the first screen used to take 26 seconds to appear. Now it takes about 2. We measured this on a simulated slow mobile connection. Fewer visitors give up while staring at a blank screen.
- Names, phone numbers and notes for 600 customers were open to anyone. Now only the shop's admin can see them.
- We also closed a way to delete bookings without logging in, and stopped two customers from getting the same time slot.
The app
A booking and inquiry app for a neighborhood hair salon (a demo). Customers pick a free time on their phone and leave a name and number. The owner confirms or cancels bookings on an admin screen. We modeled it on an app someone might build with an AI tool in a day.
What the free check-up tools found
We started with three free tools anyone can use: the check-up that comes with the database service (the place that stores customer records), Google's speed test, and a check of the software parts the app is built from.
- What they flagged: the customer records were not locked, and the first photo was far too large. That is two of the eight mistakes we built in.
- When we ran the database check on our computer with its default setup, it showed no warnings at all. The warnings only appeared after we changed one setting to match a real online service. This is exactly where someone could run the check and wrongly decide everything is fine.
What they missed
- A master key meant only for the shop's admin was inside the website files that get sent to every visitor's phone.
- There was a back door: without logging in, anyone could see, change and delete bookings.
- The admin screen's password was written right into the website files.
- Every time someone opened the booking page, it downloaded the names and phone numbers of all customers.
- Pages were never saved for reuse, so the app rebuilt every page from scratch on every visit.
What we found by hand, by actually trying things
- Once the bookings passed a certain number, the page only read the oldest ones. As a result, every slot already taken next week showed up as free. Left alone, two customers would get booked at the same time.
- Customer records could not only be read from outside. They could be changed, too.
- The page promised a text message once a booking was confirmed, but nothing in the app sends one.
To be honest
These days, if you show your code to an AI, it will point out most of these problems. We gave the same code to a separate AI without telling it what we had built in. It found all of our planted mistakes, plus one we had missed ourselves (some text was hard to read in dark mode). But it did not actually try anything to see whether the doors were really open, and it handed back a list of thirty-odd items, big and small, all at once.
Our work starts there. We pick what to fix first. We make the fixes without breaking booking, inquiries or the admin screen. Then we try each fixed item again to confirm it is really closed, and we record before and after.
What we fixed
| Problem | What could have happened | What we saw when we checked again |
|---|
| Customer records not locked | Someone could copy or edit the whole customer list | Attempts from outside to read or edit are refused |
| Master key inside the website files | That key could wipe every record | The key is gone from the website files. It now lives only on the shop's side, where visitors never see it |
| Bookings could be managed without logging in | Anyone could cancel or delete bookings | Refused unless logged in. Staff accounts without admin rights are refused too |
| Admin password inside the files | Anyone could get into the admin screen | Replaced with a real login (email and password) |
| Taken slots showed as free | Two customers in one slot | Slots now match the real bookings. If two people pick the same time at once, the second is asked to choose another time |
| First photo far too large | A long blank screen on phones | Resized for phones and loaded first |
| Every page rebuilt on every visit | Slower pages and higher server bills when traffic rises | Pages that don't change are built ahead of time. Booking availability is kept for a short while and refreshed as soon as a new booking comes in |
| Booking page downloaded all customer details | Anyone opening the page could see other customers' details | The page now gets only next week's taken times. No names or numbers are sent |
After the fixes we went through it in a real browser: making a booking, trying to book the same slot twice, sending an inquiry and logging in as admin. Everything worked.
Still to do
- A rule that blocks the following hour for long services such as perms. Every shop works differently, so this needs the owner's input.
- Protection against bots flooding the inquiry form.
- The real privacy notice, and automatic deletion once records pass their keep-by date. For now there is only a one-line sample notice.
- The admin has to log in again after a while.
How we checked
- Everything ran on our own computer with made-up data. Nothing was published, and no other service was touched.
- Before and after were measured the same way. We simulated a phone and took the middle of three runs, tried reaching customer records and admin functions from outside, and ran the free check-up tools again.
- These are lab numbers, so a real customer's phone and connection will differ. The photo is a generated image, not a real one, so it may have come out lighter than a real photo would.
- We did not try to break in, and we do not promise this rules out future problems. This report lists only what we fixed and what we saw when we checked again.
We work on client apps in the same order
We agree in writing on what we will look at. We check, pick what to fix first, fix it, then check again the same way and show you the before and after. We work in a test setup and never take your real customers' personal data. For the first three clients the check is free, on the condition that we can publish the results as a case study.