Vibe coding: what it is, what it is not, and what it means for your business

A landscaper asked us whether he could just describe the app he wanted and have it appear. The short answer is: partly, and the part that works is bigger than most people expect.

What vibe coding actually means

The term describes a way of building software where you say what you want in ordinary words and an AI tool writes the code. You type "make a page where a driver can log a vehicle inspection with photos," the tool writes the page, you look at it, and you say what to change. Nobody types the code by hand. The name comes from the feeling of it: you work by feel, judging the result on screen instead of studying every line underneath.

We do this every day. Most of the code in what we ship now is written by AI tools from descriptions we give them. That is not a confession. It is simply how the work gets done in a small studio in Delray Beach, and it is why a builder, a landscaper and a retirement advisor can each afford their own software now.

Where it works well

• Prototypes. When an owner says "I want something like this," we can have a clickable version on a real web address the same afternoon. Looking at a working screen settles arguments that a document never would.
• Internal tools. A shift schedule, a vehicle inspection form, a driver handbook with search. These have a small number of users who all work for you, and the rules are already written down somewhere. That is the ideal job for describe and build.
• Copying a proven pattern. Once a CRM works for one company, turning it into a CRM for a different industry is mostly description: new lead sources, new stages, new scoring. The hard parts were already solved the first time.
• Glue work. Sending a lead from a website form into a database, posting a summary to a chat channel, turning a spreadsheet into a page. Small, well defined, easy to check.

Where it breaks

The demo always looks fine. The trouble lives in what the demo does not show.

• Data. An AI tool will happily create a table for every screen it draws, so the same customer ends up stored in four places. Deciding what gets stored, where, and who is allowed to see it is a design job, and the tool will not do it unless someone insists.
• Security. Logins, permissions and the line between one client's data and another's. A described app often works perfectly for the one user who tested it and leaks for everyone else.
• Edge cases. What happens when the photo upload fails halfway. What happens when two people edit the same record. What happens when the phone loses signal. Nobody describes these, so nobody builds for them.
• Anything you cannot see. A nightly job that quietly stops running, an email that never sends, a database that fills up. The vibe is fine because the screen is fine.

How we use it without getting burned

1. Start from a base that already runs in production for someone else, not from a blank page.
2. Describe the work in business terms (a lead, an estimate, a shift) and let the tool translate.
3. Check the result on a live preview address, on a phone, with real data, never only on a laptop.
4. Read line by line anything that touches money, logins, permissions or another company's data.
5. Keep the code, the database and the hosting in the client's own accounts so the work is theirs whatever tool wrote it.

What this means for your business

The first version of almost anything is now cheap and quick. The question stops being "can we afford to build this" and becomes "is this worth running." Running still means someone owns it: watches it, fixes it when a supplier changes something, and adds the next feature when your process changes. Vibe coding lowers the cost of the draft. It does not remove the need for a careful second pass, and it does not remove the need for an owner.

That second pass is the part of the job we care about most. The draft is fast for everyone now; the checking is what separates software that runs a business from software that runs a demo.

Questions people ask