They Tried Vibe Coding. Then They Hired Me.

A new type of enquiry has started coming to me.

The business owner does not begin with, “Can you build an app?”

Instead, the opening message is something like:

“I already built most of it using AI. I just need somebody to help me finish the last bit.”

That “last bit” is sometimes half the project.

They may have used Lovable, Bolt, Replit, Bubble, ChatGPT or another AI app builder. The beginning went very well. A prompt became a screen. Another prompt became a form. The buttons had gradients. The dashboard had charts. For a short and beautiful moment, everyone felt like Iron Man.

Then real business entered the room.

The customer record needed to connect to an old database. Two staff roles required different permissions. A payment could be split into deposit and balance. An API behaved differently from its demo. One small change broke three other things. The AI kept “fixing” the same bug in exciting new ways.

That is usually when they call me.

This is not an article attacking vibe coding. I use AI tools in my own development work. They can be extremely useful. But the experience has shown me why business owners still hire software developers after trying to build an app with AI.

The answer is simple: most clients do not want to become developers. They want their business problem solved—and they want a human being who understands it and takes responsibility for the result.

What is vibe coding?

Vibe coding is a way of creating software through natural-language instructions. You describe the app, page or feature you want, and an AI tool generates the code or assembles the application for you.

It can be brilliant for testing an idea. A business owner can turn a rough concept into something visible without spending weeks learning programming syntax. A developer can use the same tools to move faster through routine work.

But a generated screen is not automatically a finished business system. The difficult part of software development was never only typing code. The difficult part is understanding what must happen, what can go wrong, what connects to what, and who will be responsible when Monday morning arrives and twenty staff need the system.

Business owners already have a full-time job

Most of my clients run businesses. They sell, hire, quote, schedule, chase payments, answer customers and solve daily problems. They are not sitting around wondering how to spend their spare six hours debugging an authentication callback.

An AI platform may make software creation look easy, but somebody still has to:

• describe every important rule;
• check whether the generated result is correct;
• investigate errors;
• manage data and user permissions;
• connect external services;
• test unusual cases; and
• maintain the application after launch.

For a business owner, this can quietly become a second job. The platform has saved the cost of a developer by turning the client into an unpaid junior developer. Very innovative.

Some clients eventually ask me to manage the vibe-coding platform itself. That can work if the existing foundation is sound. In other cases, an audit shows that continuing on the same foundation will cost more than rebuilding the important parts properly.

They want to talk to a human in a human way

Many first conversations begin with a combination of these lines:

“I don’t know exactly what I need.”

“My current system is messy.”

“The previous developer disappeared.”

“I started building it myself, but now I’m stuck.”

This does not mean the client has failed to prepare. Business owners often understand their operation very well. They simply do not describe it using software language.

My job is to ask leading questions that allow them to open up:

What happens after an order comes in? Who approves it? What information is missing most often? Where do mistakes happen? What does the accounts person need? What happens when the normal process is not followed? Which part causes the most WhatsApp messages?

Every answer reveals another piece of the real system.

An AI tool responds to the requirement it receives. An experienced developer helps uncover the requirement that has not yet been said.

This human preference is not imaginary. In its 2025 customer-experience research, PwC reported that 86% of consumers considered human interaction moderately or very important in their brand experience. Technology can make service faster, but people still value a person who listens and owns the next step.

The business owner with one large order book

One client in the curtains and blinds industry called me while his business was growing quickly. This sounds like a nice problem until every order, installation date, payment and commission is living inside one large physical book.

There were several salespeople and installers. Customers paid a deposit and a final balance. Installation schedules could clash. Commissions had to be calculated. The owner sent me a WhatsApp video of himself rummaging through the book to show how the operation worked.

“It is pure havoc,” he said.

He also told me he had no IT background and did not know how to explain what he needed.

That was fine. He did not need to arrive with a database diagram. He needed to explain his business, while I asked the questions that turned the daily chaos into rules, screens and workflows.

The result was a custom CRM and management system for the curtains and blinds business. It brought customer records, sales, payments, staff commissions and installation schedules into one organised place.

Could an AI app builder generate a customer form? Certainly. The valuable work was understanding how this particular company operated and turning many connected problems into one usable system.

A prompt is not a requirement

A prompt describes what someone currently thinks they want. A software requirement describes what the system must do across normal situations, exceptions, failures and future changes.

Suppose the prompt says:

“Build an order management app with commissions.”

Immediately, I have questions. Is commission calculated on the quoted amount, collected deposit or final payment? What happens after a refund? Can two salespeople share one sale? Can an administrator override the figure? Must the change be logged? Which date determines the reporting month?

The first screen may look correct while the underlying assumptions are wrong. Attractive software can still produce unattractive accounting conversations.

The first 70% can be very impressive

Vibe-coding platforms are excellent at making progress visible. Within hours, a user may have login pages, navigation, forms, sample records and a polished dashboard.

The remaining work is less photogenic:

• consistent data structures;
• permissions and access control;
• validation and error recovery;
• performance with real records;
• backups and migrations;
• third-party API failures;
• security reviews; and
• maintenance after the platform or model changes.

That is why “almost finished” software can remain almost finished for a very long time.

The 2025 Stack Overflow Developer Survey found that 66% of developers were frustrated by AI solutions that were almost right, while 45% said debugging AI-generated code could take more time. Those numbers match what clients experience: producing code is fast; proving that it is correct is still work.

“Almost correct” software can become expensive

A spelling mistake on a brochure is embarrassing. An “almost correct” commission calculation can affect salaries. An “almost correct” permission rule can expose customer information. An “almost correct” booking workflow can promise the same slot to two customers.

Business software sits inside real operations. It has consequences.

When clients hire me after trying a DIY platform, they are often paying for certainty: an experienced person to inspect the logic, identify hidden assumptions, test what happens at the edges and say clearly which parts are safe to keep.

The platform does not know what it does not know

AI generates answers from the context available to it. It does not automatically know the unwritten history of your company.

It may not know that a long-standing customer receives special terms, an installer can only cover certain areas, a product requires a second site visit, or the accounts team closes the month in a particular way.

A human developer learns these details through conversation, observation and repeated clarification. This is also why I ask clients to show me existing spreadsheets, forms, WhatsApp messages and even their notebooks. The messy artefacts often explain the business better than a perfect proposal document.

Integration is where the easy demo meets the real world

A standalone prototype lives in a comfortable little universe. A working business system must communicate with payment gateways, accounting software, email providers, maps, messaging services, old databases and staff devices.

External systems have authentication rules, rate limits, incomplete documentation and occasional outages. Data arrives in unexpected formats. A service changes its API. A token expires at the exact moment the person who understands it goes on leave.

I built a Singapore accident alert Telegram automation that filters incident data, prevents duplicates, formats useful alerts and provides direct map actions. The visible Telegram message is the easy part. Reliability comes from the processing, state management, retry behaviour and integration behind it.

This is where software development becomes engineering rather than screenshot generation.

Security is not visible in the screenshot

A beautiful login screen does not tell you whether passwords, sessions and permissions are handled safely. A working database connection does not tell you whether one customer can access another customer’s records.

Research reviews of AI-generated code have repeatedly identified security weaknesses, including insecure defaults and vulnerable patterns. The correct response is not to ban AI coding. It is to review generated code like generated code—carefully, with tests, restricted permissions and somebody accountable for the final design.

For business applications, I look at who can see each record, how inputs are validated, where secrets are stored, what gets logged, how backups work and what happens when a service fails. None of this creates an exciting launch video. All of it matters when the software holds real data.

Sometimes I recommend WordPress instead

I have advised clients not to build custom software when an existing product makes more financial sense.

I have done this since the early WordPress days. If a business needs a straightforward content website and WordPress solves the problem cleanly, there is no prize for spending more money on a custom content-management system.

The same principle applies today. Sometimes the answer is a ready-made CRM. Sometimes it is a small automation. Sometimes the client should continue using the AI platform with a little technical help. Sometimes the workflow is specialised enough to justify custom software.

A developer who understands the business should help choose the appropriate tool—even when the recommendation produces a smaller invoice.

Yes, I use AI to develop software

I do not sit in a dark room protecting a sacred keyboard from artificial intelligence.

I use AI tools for research, planning, exploring approaches, generating routine code, reviewing changes, creating tests and improving documentation. They make me faster. They can also suggest an answer that looks extremely confident and is extremely wrong. That combination keeps life interesting.

The important distinction is responsibility.

I do not tell a client, “The AI wrote it, so please ask the AI why your invoices disappeared.” I decide what to use, inspect the output, test the result and remain personally responsible for the system delivered.

AI changes how I work. It does not remove my obligation to understand the work.

Vibe coding changes my job rather than removing it

Some clients can now create their own first prototype. This is useful. Instead of explaining a vague idea for twenty minutes, they can show me something and say, “I want this part, but the rest is not working.”

My role then moves toward:

• asking the questions the tool did not ask;
• separating the useful prototype from fragile code;
• designing the data and system architecture;
• connecting real business services;
• testing security and failure cases;
• planning a sensible path to production; and
• remaining available when the business changes.

The keyboard work may become faster. Judgement becomes more valuable.

Clients are buying an outcome

Clients rarely wake up wanting PHP, JavaScript, APIs or database indexes. They want fewer booking clashes, faster quotations, accurate commissions, organised customer records and less time searching through WhatsApp.

They also want somebody to translate between technical choices and business consequences.

Should this feature be included now or later? Will the platform become expensive at higher usage? Can staff export their data? What happens if the vendor changes its terms? Can another developer maintain the system? These are ownership questions, not prompt-writing competitions.

Clients also want continuity

Software changes because businesses change. A new staff role appears. A report needs another column. A payment provider updates its API. A successful operation develops new exceptions.

Clients from many years ago still contact me for additions and changes. I handle this work on an ad-hoc basis rather than forcing every client into a monthly support fee. I explain that approach in Why I Don’t Charge a Retainer Fee.

Source-code ownership varies by project. Full ownership can be transferred on request. In other arrangements, I keep the code so future maintenance and additions remain straightforward. The correct arrangement is the one discussed clearly before the project, without mystery clauses appearing after everyone has become emotionally attached to the dashboard.

What clients are really paying me for

They are paying for code, but not only code.

They are paying for someone to listen to an incomplete explanation and find the real problem. They are paying for questions, judgement, architecture, debugging, testing, integration, communication and accountability.

They are paying for the sentence:

“Don’t worry. I understand what you are trying to do. Let us work through it.”

That sentence cannot replace technical skill. But technical skill without that sentence can be very tiring for a non-technical client.

Vibe coding is a tool, not the person responsible

Vibe coding will continue to improve. More business owners will create prototypes, internal tools and even useful production applications. That is a good development. Software creation should become more accessible.

But ease of generation does not remove the need to understand the business, test the result, protect the data and support the system. It changes where the hard work begins.

If you enjoy building and your app has a manageable scope, continue experimenting. If the project is becoming important to your operation, ask an experienced developer to review it before the clever prototype becomes a critical mystery.

If you started with Lovable, Bolt, Replit, Bubble, ChatGPT or another platform and are now stuck, you do not need to be embarrassed. You have already done something useful: you made the idea visible.

I can help assess what you have, identify what can be kept and recommend whether to stabilise, extend or rebuild it. Explore my custom software development services in Singapore, read more about vibe-coding risks for business apps, or tell me where your project got stuck.

Have you tried building an app with AI? Which part was easy, and where did the real trouble begin?