← Back to the blog
30 October 2026

Okay, But Actually… Before You Launch That Vibe-Coded App

Okay, But Actually… Before You Launch That Vibe-Coded App

I saw this on Facebook:

“I’M F*CKING BEGGING YOU, MAN:

  1. Launch your software idea with vibe coding!”

I use AI in my work. I can see why somebody with a software idea would use it to make a rough version. A screen you can click is much easier to think about than an idea you have explained seventeen times with your hands.

It is the word “launch” that bothers me.

A prototype can be ugly, unfinished and held together by whatever worked at two in the morning. Its job is to help you work out whether the idea deserves any more of your life. Once you give the link to strangers, take their details or accept a payment, the experiment has acquired customers. They will expect it to work even if you put “just testing haha” above the link.

The business owner already has a job

Imagine a salon owner who hates her current booking system. It handles deposits badly and makes moving an appointment far more annoying than moving a person from Tuesday to Wednesday has any right to be.

She knows what the salon needs. She knows which services can follow each other, how long the room has to be empty between treatments and what happens when a client is late. She should be involved in building a replacement. For most busy owners, that means explaining the salon to whoever builds it and checking that the result fits the way people actually work.

If she wants to learn, good. A real project will teach her more than another tutorial about making a to-do list. She can build a private prototype and enjoy learning how it works.

A busy owner without a development budget is usually better off using an existing booking system. It may be annoying and it may force the staff into a few daft workarounds. Use it anyway. Perfect can wait until the business can pay for custom work without turning the owner into an unpaid junior developer.

She can keep a list of what the current system gets wrong. When the business has the money, that list becomes useful input for somebody building a replacement. Until then, the existing system takes the bookings while she gets her evenings back.

She also needs enough knowledge to judge what the tool gives her. The booking page may look finished while the code behind it accepts two customers for the same slot. It may send a confirmation before the payment has gone through. The owner can test the booking she expected to make and never discover that changing one number in the page address opens somebody else's appointment.

A salon owner cannot learn to judge all of that from a few evenings of prompting. Doing it properly would mean spending a year or two learning development from reliable sources. She already has a profession.

Give the rough version a smaller job

The salon owner can test the idea without opening her homemade booking system to Facebook.

She can show a mock-up to regular clients and watch where they get confused. If she wants to sell a new package, she can take a few bookings manually before building special software for it. The receptionist who fixes the current diary every day will probably spot a bad rule before any customer does.

Those small tests answer the earlier question: is this idea useful enough to build properly? The finished app will need its own work later.

That is where vibe coding makes sense to me. It can turn a conversation into something people can react to. Sometimes the reaction will be, “Oh, I thought you meant something completely different.” Excellent. You found out before anybody spent three months building it.

Keep the test honest. Five people who agreed to try an unfinished prototype are testers. A public link is a launch, because the people clicking it did not agree to help you debug your new hobby.

The happy path is the easy bit

The owner books a haircut for Tuesday at ten. She pays the deposit and receives the right email. Lovely.

Now let two customers choose Tuesday at ten within the same second.

Cancel one booking. Move another after the deposit was paid. Remove a stylist's account while she still has future appointments. Ask for a refund. Turn off the email service for an hour. These are ordinary events in a salon, and the app has to deal with them without inventing money or losing a customer.

Testing all of that is work. Deciding where customer details are stored is work. Somebody needs to know what to do when a payment succeeds but the booking does not appear.

The salon owner should explain how the business handles those situations. A developer turns those answers into rules, checks the generated code and tests the cases that did not happen during the owner's first click through.

That is a normal reason to pay for custom development. AI gives the owner another tool. She still has the same number of hours in the day and the same amount of development experience. She can pay someone to build and look after the booking system while she runs the salon.

Use vibe coding to make the rough version if it helps you decide what to build. Keep it away from real customer details and money while it is still an experiment. Once strangers use it for a real booking, it is part of the salon. Double bookings are one possibility. A payment can succeed without creating an appointment, an account can expose another client's details, or a cancellation can go wrong in a way nobody tested. The owner has to deal with whichever problem appears first.

Want a site like this?

Take a look at the packages, or just say hello.

See the packages →