Building Apps: Services Where Data Lives

Eleven at night, and the beauty studio owner's phone buzzes softly. A booking just came in for tomorrow at 2 p.m. The customer browsed treatment photos in the app, picked an open time slot, booked it, and the record stacked itself into the admin dashboard. All the owner did was press confirm in the morning.

That app is what we build in this course. Not a page that only shows things, but a service that takes bookings, remembers customers, and hands the owner a management screen. If the courses so far taught you to make the sign, now we build the whole shop.

Don't let the word Advanced tense you up. The AI does the hard parts. You decide what kind of shop to build.

What separates a web page from an app isn't flash, it's memory. A page shows the same thing to everyone, and when a visitor leaves, nothing remains. An app is different. A customer books and the booking stays; they return and it recognizes them; the accumulated records fill the admin screen.

So an app needs three parts a page never had: a store for the data (a DB), a login to tell people apart, and screens that change with state. Those three parts are the protagonists of this course.

Not sure whether your idea needs to be an app? Ask this: 'does what a visitor leaves behind need to still be there tomorrow?' If yes, it's an app.

Time to break ground. Press Try it now below and the beauty studio booking app's skeleton prompt is filled in: time slots, customer login, an admin dashboard to manage bookings. An order slip that names all three of an app's big parts.

Confirm the build type says app, then send. Since we're rehearsing something meant for customers, Deep Build is recommended. You'll watch the product spec pin down the screen flow and the data structure with your own eyes.

It's okay to get it wrong; regenerating is free. Apps have many parts, so an imperfect first pass is the norm, and this entire course is the polishing process.

Two kinds of people walk into an app: customers and the owner. Drawing their two paths separately is the heart of screen-flow design. The customer's path: browse treatments, pick a slot, log in, confirm the booking, view my bookings. The owner's path: admin login, today's booking list, confirm or cancel, manage time slots.

Say these paths, arrows and all, in your prompt or in blueprint feedback and the AI lays out the screens precisely. Requests about order are especially valuable, like 'let customers browse without logging in, and require login only right before confirming a booking'.

Why flow first? Because any single screen's design is easy to fix, but an app with tangled flow has to be rebuilt from the bones.

The instant a customer taps the booking button, where does that booking go? If it lives only on the screen, one refresh evaporates it. So an app needs a refrigerator. A database (DB), a store where whatever you put in is still there when you open it tomorrow.

Inside, the refrigerator is organized into compartments. The customers compartment holds names and contacts, the bookings compartment holds dates, time slots, and staff, the treatments compartment holds menu and prices. Divide the compartments and you can pull out exactly what you want: 'all bookings this week' or 'the regulars list'.

Good news: the AI is good at compartment design. Remember the data model section in the Deep Build spec. All you need to guard is 'what must be stored'. For a booking app, customers, bookings, and treatments have to be on that list.

Whose name goes on that refrigerator? That is the question BYO answers. VibeCampus supports connecting your very own Supabase directly to the Studio, so core business assets like your customer list and booking records stack up in a warehouse you own from day one.

Connecting is not hard. Sign up for Supabase, create a project, and you receive an address (URL) and a key. Enter those two values in the Studio's connection settings and you're done. As the example below shows, they're kept in the safe called environment variables, never written into the code.

Why go this far? Because whose name is on the data decides how independent your business is. Data in your own warehouse can be picked up and moved, whole, at any time. Lock down this step's vocabulary with the four cards below.

$# .env — your own Supabase, connected in the studio (BYO)
$SUPABASE_URL=https://xxxx.supabase.co
$SUPABASE_ANON_KEY=eyJhbGciOi...

Once bookings start saving, the next question arrives immediately: whose booking is this? That's why login exists. Login is the doorkeeper. It shows each customer only their own bookings, and opens the admin screen to the owner alone.

When you ask the Studio, set the level. For a light touch, email login; to lower the threshold, social login; and keep admin as a separate privilege. One sentence, 'social login for customers, a separate admin account for the owner', and the AI hangs the door and the lock together.

An app's data quality is decided at the form. A customer will type 'text me please' into the phone number field, or book a date in the past; it always happens. Input validation is the device that turns those weird values away at the door, before they get saved.

The technique is listing the rules: 'phone numbers digits only, booking dates today or later, name required'. And prepare the rejection copy too. 'Please enter digits only for the phone number' loses fewer customers than 'Invalid input'.

If the customer side is the storefront, the admin screen is the cockpit. Today's booking list, confirm and cancel buttons, opening and closing time slots, simple stats. The owner opens it every morning, so at-a-glance beats flashy, every time.

When you ask, phrase it as the owner's day: 'when I open it in the morning I see today's bookings in time order, confirm and cancel buttons beside each one, and a summary of this week's booking count at the top'. Requests that carry the real operating routine produce cockpits that get used.

Attach payment to bookings and no-shows fall while revenue arrives earlier. In the Studio, you can build the payment flow in demo mode first: amounts, the pay button, the completion screen, all working exactly like the real thing while no actual money moves.

Why demo first? Because payments are nine-tenths flow design. When to ask for payment (before confirmation? after the visit?), what happens on cancellation. Polish those rules thoroughly in demo, then switch to live payments once your payment provider is ready. That's the safe order.

Customers will use this app on their phones. Open both iPhone and Galaxy frames in phone preview, and check that the time-slot buttons are thumb-sized and the scroll to booking isn't long. Form input in particular turns hellish on phones, so the best check is completing one booking, start to finish, inside the phone frame.

And a tip to pass on to your customers: the browser's add to home screen puts your app on their phone as an icon. It gets used like an installed app without ever touching an app store. Worth telling your regulars in a little note.

A launched app keeps growing. Customers ask for things, menus change, one more screen becomes necessary. On VibeCampus there are three paths for raising an app. First, refine chat: fastest for everyday spoken edits. Second, Click to edit: hands-on micro-adjustment of copy and design. Third, the handoff pack: download the entire code and pass it to external dev tools or a developer, the road for major construction.

Most days, the first two are plenty. The third path matters because of what it means: reassurance. At no moment is your app trapped inside this platform.

The handoff pack is your build's moving boxes. Download it and you get the finished code plus a README covering how to run and host it, plus AGENTS.md, the handover brief for AI dev tools, all in one zip.

Unzip it and open it with tools like Claude Code or Cursor, and you can keep developing outside exactly where you left off. Hire a developer someday and this one pack is the handover paperwork. Forms and member features come prepared to keep working, so business runs from day one after the move.

It wasn't built so you'd leave. It was built so you could stay at ease, because you can leave. No asset of your business ever becomes a hostage. That is this platform's promise.

The final hands-on. Press Try it now below and a habit tracker app prompt is filled in: a daily checklist, a streak counter for consecutive days, a weekly progress chart. A completely different subject from beauty studios, to test whether the learning became real skill.

There's one gate that matters: is the data truly alive? Check something off, refresh, and see with your own eyes whether it survived.

When this course began you were someone who makes screens; now you're someone who builds services. Designing flows, claiming the data's ownership, posting a doorkeeper, installing a cockpit, ordering the payment steps. This is what building an app really means.

The skeleton you learned transplants into any industry. A beauty studio becomes a hair salon, a habit tracker becomes a book club attendance sheet, with a few words' difference in the prompt. Next up is an idea of your own.