My friend replaced his software vendor in a weekend — then I asked him one question

By the Owners, Commerce Online 4 September 2026 9 min read

My friend runs a small business. Five technicians, a phone that never stops, and a booking system rented from a vendor for years. Cheap, clunky, and doing about seventy per cent of what he needed.

He had asked for the other thirty per cent every year since 2023. Every year: it is on the roadmap.

Last month he sent me a link. He had rebuilt the whole thing over a weekend, describing what he wanted to an AI and correcting it until it behaved. It looks better than the old one. It does the missing thirty per cent. It costs him nothing.

The correct first reaction to this is not concern. It is envy.

A man who has never written a line of code closed a three-year gap in eleven hours. For years he had been a tenant in someone else’s software. In one weekend he stopped being one.

I felt all of that. Four seconds later I started forming a list. This is the list. None of it argues against what he did. All of it is about what happens next.

First, the part that is not a warning

Three things are true before any of the concerns are.

The speed is not hype

He solved in a weekend what a software company had not solved in three years.

He is the best person to specify it

Nobody understands his workflow better. He skipped the requirements document entirely.

And it is not going back in the box

Most use of AI coding tools is now by people with no engineering background.⁴

The full case for all three

The speed. That three-year gap is not a fluke of one project. It is why this is happening everywhere at once.

The specification. Every requirements document ever written was an attempt to move an owner’s understanding of their own business into someone else’s head. He skipped the transfer.

The adoption. One survey puts non-engineers at 84% of AI coding tool users, another at 63%.

So the question was never should he have. It was what did the old vendor quietly do that nobody has taken over.

Four things I would want checked before Monday

None of these need him to understand code. Three need one hour of someone else’s attention. The fourth needs a decision he has not knowingly made yet.

Any customer can read every other customer’s booking

The most common failure by a distance, and almost always the same shape. The app checks who you are when you log in, then never again. Change the booking number in the address bar from 4417 to 4418 and you are reading a stranger’s name, address and phone number.

This is not hypothetical. One scan of 1,072 apps built this way found 98% carried at least one security flaw.²

Two more places this has already happened

Missing row-level access rules are common enough to have their own catalogued vulnerability.³

One social app built the same way was breached three days after launch: 35,000 email addresses out of a database with no row-level security.⁵

The bit that does not transfer. Under Singapore’s Personal Data Protection Act, his business is responsible for that data. Not the AI tool. Not the free host. If four hundred addresses leak, the PDPC and the customers arrive at his door — on a clock he does not know is running.

Notice what left the building. The old vendor was slow, but it had a security posture, a support line and a commercial reason not to leak anything. He was paying for that, and it was never a line on the invoice.

Why he has no way to notice this

The app behaves perfectly in testing, because when you test your own app you only ever look at your own booking.

Nothing is slow, nothing crashes, no warning appears. There is no symptom to spot, and no vocabulary to ask about it with.

“It runs” and “it is safe” are different questions

Describing software to an AI removes the friction of writing it. It also removes the person who used to catch the mistakes.

Veracode tested more than a hundred models. Given a choice between a secure and an insecure way of doing something, they chose insecure about 45% of the time.¹

The safety net nobody mentioned

Traditional software development had a slow, expensive step called code review, and its whole purpose was catching what the author could not see.

That step is gone from this workflow, and most people building this way do not know it was ever there. They are not ignoring a safety net. They have never been told one existed.

The keys are in the door

Passwords and access keys written straight into code that gets sent to the visitor’s browser. Scans of apps built this way routinely turn up hundreds of exposed credentials.

In his case: the credentials to the database holding every customer he has ever served, in plain sight. Not stolen, not cracked. Published.

A fifteen-minute fix and a five-minute check. It is on the list only because nobody has looked.

The system got promoted, and nobody held the meeting

None of this matters much for a weekend experiment. His did not stay one. It went straight into the slot a paid, vetted system used to hold: how customers reach the business, and how five technicians know where to be tomorrow.

That promotion took an afternoon, on the strength of it works when I try it. No review, no handover, no moment where anyone decided this was load-bearing.

The old vendor spent three years earning the right to run his bookings. The replacement inherited it in a weekend, and nobody in the building noticed a decision had been made.

This is the actual risk. Not the code — the promotion.

What I eventually told him

Two moves. Neither of them is “stop”, and neither costs what he is probably bracing for.

Ask a friend. Not a vendor — a friend.

One person who reads code, one hour, three questions. That is the entire intervention.

1. Can one customer see another customer’s booking?
2. Where are the passwords and keys stored?
3. If this disappears tomorrow, who has a copy of the data?

Almost every owner already knows someone who can answer those. Almost none think to ask, because the app works. The barrier is not cost. It is that a second opinion does not occur to you about something you watched build itself.

Treat what he built as the prototype, not the product

The expensive part of building software was never the typing. It is working out what the thing should do — and he has already done that.

He has a working, opinionated artefact showing exactly what he wants, built by the person who knows the business best. Handing that to a professional is not surrender. It is arriving with the expensive question already answered.

Why the specification is the expensive part

The workflow, each screen, which edge cases matter: that is what burns months of discovery meetings, and it is the part that most often comes out wrong.

Every requirements document is an attempt to move an owner’s understanding of their own business into someone else’s head. A working prototype skips the transfer.

The question, in the end

What I should have asked was not is it secure, which is unanswerable over a coffee, and not who built it, which sounds like an accusation.

If this stops working on Monday, or starts working for the wrong person, who finds out first — you, or your customer?

He did not have an answer. Most people in his position do not, and that is not a failure of judgement. A year ago, buying software meant buying somebody else’s answer with it. Now the software is free and the answer is not.

He still built the right thing. He just has not finished.