I recently saw someone warning businesses about custom software, solo developers, and people who build with AI.
He wrote:
“There’s going to be massive backlash on a lot of these vibecoded, solo dev apps in the coming years.”
I agree with that sentence.
Some of the apps being launched right now should not be anywhere near real customer data. They have authentication that has never been properly tested, database permissions generated by AI that nobody has tried to break, no monitoring, no useful logs, and no plan for what happens after launch.
People are even vibe-coding apps that collect medical information.
That can include symptoms, diagnoses, medication, test results, and notes about someone’s mental health. The rules vary by country, but this is not ordinary customer data.
In the EU and UK, health information receives additional protection under the GDPR and UK GDPR. In the US, HIPAA applies to certain healthcare organisations and their business associates. It does not automatically cover every health app. Some apps outside HIPAA may instead have obligations under the FTC’s Health Breach Notification Rule.
If an app is going to store someone’s diagnosis, the person building it needs to understand which rules apply and how that information will be protected before asking anyone to use it. This is not something to figure out after launch.
Where the comment loses me is when it turns these problems into an argument against custom software, solo developers, and AI-assisted development all at once.
Those are three different things. None of them automatically tells you whether an application is safe.
Shipping the first thing AI gives you is obviously a bad idea
AI can get an application onto a screen remarkably quickly.
You can describe what you want, generate an interface, connect a database, add a login page, and deploy something that appears to work.
Most early builds have only been used by the person who made them. There is one test account, a small amount of clean sample data, and a developer who already knows exactly which button to press next. That is a very friendly test of an application.
Real users will not be as helpful.
Someone needs to check whether one user can access another user’s records, what happens when a large file is uploaded, whether clicking a button twice creates two payments, and how the application behaves when an external service is unavailable.
Passwords need particular care because people reuse them. A password exposed by one careless application may also unlock that person’s email, social media, or other accounts.
An application should not store readable passwords. If it handles passwords itself, they need to be salted and hashed using an appropriate password-hashing scheme.
Of course, “salted and hashed” is exactly the kind of phrase some people love to drop into a post because it sounds technical and important.
There are people selling themselves as developers who are really marketers with a collection of impressive terms. Knowing the words does not mean they know how authentication works. Saying “we use military-grade encryption” in bold text beside a padlock icon does not count as a security review either.
Ask them about password resets, leaked-password checks, rate limits, sessions, multi-factor authentication, access control, and what happens if credentials are compromised.
Then ask follow-up questions.
AI can produce a polished answer full of the correct terminology in seconds. That is useful when someone is researching or checking a detail. It is less reassuring when the person who built your system cannot explain their own decisions without secretly asking AI what those decisions mean.
If you are discussing a project on a call and the developer suddenly cannot explain how access works, what they would do after a breach, or why they chose a particular approach, pay attention.
Using AI is not the problem. Depending on it to impersonate understanding is.
Current NIST guidance says passwords should be stored in a form designed to resist offline attacks, using a suitable salted password-hashing scheme. It also recommends checking new passwords against lists of commonly used or compromised passwords and allowing password managers.
For my own projects, I use Supabase Auth.
Supabase handles password storage using bcrypt and can reject passwords known to have appeared in breaches. It also supports options such as multi-factor authentication.
That does not mean I add Supabase and declare security finished. Supabase Auth verifies the user’s identity. I still need to configure the authentication settings correctly and write and test the Row Level Security policies that control which records each user can access.
Using a specialist provider gives me a well-tested foundation. I still have to build responsibly on top of it.
This is where inexperienced builders get into trouble. AI gives them a lot of visible progress before they have learned about the work that is harder to see.
They do not know which questions they should be asking, so they assume there are no more questions.
That becomes a serious problem when the application handles passwords, payments, private conversations, financial information, or health data.
The issue is not that the software was custom-built. Somebody launched software they were not qualified to take responsibility for.
Custom does not mean we build everything ourselves
The comment also assumes that custom development means building an entire technical stack from scratch.
It usually does not.
We are not inventing our own database for every client. We are not creating a payment network because Stripe was too mainstream. We are not spending a long weekend developing AnaCrypt™, an exciting new encryption method based mainly on confidence.
Custom applications use existing services and infrastructure all the time.
Hosting can be managed. Authentication can be provided by a specialist service. The database can be managed. Payments can go through a payment provider. Email delivery, file storage, error tracking, backups, and monitoring can all use established tools.
Using these services does not make an application automatically safe. They still need to be configured correctly. Permissions need to be written and tested. Privileged credentials need to stay private. The developer needs to understand how the pieces work together.
That is very different from one developer attempting to recreate every part of the internet alone.
The custom work is normally the part that is specific to the business: its workflows, rules, integrations, interface, and the problems existing platforms do not solve well.
Knowing what to build and what not to build is part of being a good developer.
Sometimes buying software is the right answer
I build custom software, but I do not think every business needs it.
If an existing platform already does what a business needs, fits the way it operates, meets its requirements, and charges a reasonable price, using it may be the obvious decision.
There is no prize for spending six months building something you could have bought for €40 a month.
SaaS can also take a lot of technical work away from the customer. The provider may handle infrastructure, operating systems, updates, availability, and many other things a custom project would otherwise need to consider.
That is a real benefit.
What I disagree with is the idea that choosing an established platform makes security somebody else’s problem.
You can see this in the tools many businesses and marketers already use.
WordPress gives you a mature platform, but someone still has to choose the hosting, manage user accounts, install plugins, remove the abandoned ones, apply updates, and keep backups. WordPress’s own security documentation says keeping WordPress, its themes, and its plugins updated is one of the most important parts of protecting a site.
WordPress cannot stop an administrator from installing a questionable plugin and giving it access to half the website.
HighLevel is an interesting example because it has the credentials people point to when they want reassurance. HighLevel says it undergoes annual SOC 2 Type II assessments, and its Trust Center says it uses recurring vulnerability scanning and annual third-party penetration testing.
Those are meaningful controls. They are not proof that every part of the product has always been secure.
HighLevel’s own documentation shows that it has recently been tightening its legacy API security. Its enhanced security changes stopped API keys from being generated automatically, removed API keys from certain API responses, and restricted old user-management endpoints. HighLevel says those legacy endpoints could be used to attack an account if someone obtained the API key. It has also started expiring inactive legacy API keys to reduce unnecessary exposure.
Making those changes is good. It also demonstrates why a certificate should not end the conversation.
A company can pass audits, run penetration tests, employ a large engineering team, and still find things that need to be redesigned or locked down. That is normal in software. The worrying part would be pretending it never happens.
Customers still have their own work to do. HighLevel provides two-factor authentication and detailed user permissions, but the agency decides who gets access, which permissions they receive, which integrations are connected, and whether old accounts are ever removed.
HighLevel cannot know whether the freelancer you hired six months ago should still be able to export every contact in every client account.
The same applies when using Systeme.io or ClickFunnels. The platform looks after the service it operates. The business still decides who can log in, what information to collect, which integrations to connect, who can export the data, and where that exported data ends up.
Buying software can reduce the amount of technical work a business has to manage. It does not mean every security and privacy decision has been made for you.
AI still needs someone who knows what they are looking at
I use AI every day. So does Pedro.
It saves us time. It can write repetitive code, suggest different approaches, help investigate problems, and give us a useful first version to work from.
I treat that output as a first version, not finished work.
AI-generated code still needs to be understood, reviewed, and tested. GitHub says the same thing in its guidance on reviewing AI-generated code. Generated code can contain mistakes and security problems.
One study involving an AI coding assistant found that participants produced less secure solutions for certain security-related tasks while also being more likely to believe their solutions were secure.
It was one study using one assistant, so I would not turn it into a claim about every developer and every current AI tool. It does show why generated code needs to be checked, even when the result looks convincing. The study is available here.
AI does not know whether an application is safe just because it successfully generated the requested feature.
It does not know the full context of the business. It does not know what information the company is legally allowed to collect. It does not know whether a particular failure would be a minor inconvenience or expose somebody’s medical history.
The person using it needs to understand those things.
If they do not, generating more code more quickly does not help.
One developer is not automatically an amateur
There are fair reasons to ask questions about hiring one developer.
What happens if that person becomes unavailable? Is the project documented? Can someone else take over? Who reviews security-sensitive work? Is maintenance included, or does everyone wave goodbye after launch?
A business should ask those questions.
It should also ask them when hiring an agency.
A larger team may have more specialists and more people available when someone is away. That is valuable.
It may also put the entire project in the hands of a junior developer while the client communicates through several layers of project management.
The number of people in the company does not tell you who is actually building your product.
I would rather judge the people doing the work.
Can they explain their decisions? Do they understand the risks? Do they test permissions and failure cases? Is the system documented? Have they planned for updates and maintenance? Can another developer work on it later?
Those answers tell you far more than the team photo on an agency’s About page.
The boring work still has to happen
Generated code gets reviewed. Authentication and permissions are tested. Sensitive credentials are kept out of public code. Information is validated before the application accepts it. Development and production are kept separate.
There are backups. There are logs that are actually useful. Important errors trigger alerts instead of waiting for a customer to discover them.
Dependencies are updated. Security fixes are applied. Important parts of the system are documented. Somebody remains responsible after launch.
The NIST Secure Software Development Framework includes identifying and responding to vulnerabilities in released software. Launching is one stage of the work, not the moment everybody gets to stop thinking about it.
The amount of process should match the product.
A private prototype being tested by two people does not need the same controls as a medical application used by thousands. Pretending those two products carry the same risk would be absurd.
You need to know what you are building, what information it will hold, who will use it, and what must be ready before its responsibilities grow.
Ask more useful questions
If you are considering hiring someone to build custom software, “Do you use AI?” is not a very helpful test.
A developer can avoid AI completely and still write terrible software manually. We did not need language models to invent security vulnerabilities.
Ask this instead:
- What information will the application collect?
- Does it actually need all of that information?
- Who will be able to access it?
- How will those permissions be tested?
- Which parts are custom and which use established services?
- What happens if an external service stops working?
- How will errors and suspicious activity be detected?
- What is the backup and recovery plan?
- Who handles security updates after launch?
- What documentation will we receive?
- Could another developer take over the project?
- What do you think the biggest risks are?
Nobody credible can promise that software will never have a problem.
The developer should be able to explain the risks without hiding behind technical vocabulary. They should be able to show you what they are doing about those risks and tell you who will remain responsible after the product is launched.
If they cannot do that, whether they use AI is the least interesting thing about them.
Custom software is not the thing to be afraid of
I am not defending careless AI development. I have seen enough rushed software to know why people are worried.
An app built by someone who does not understand security can be dangerous. An app collecting medical data without the right knowledge and safeguards can be much worse.
We should be talking about that.
Telling businesses that custom software is inherently unsafe does not help them make better decisions. Neither does treating every solo developer like a first-time vibe coder or assuming a familiar platform has taken care of everything.
Find out who is doing the work. Ask how they make decisions. Ask what happens after launch. Ask how they protect the information you are asking customers to trust them with.
If the answers are vague, do not hire them.