Okay, But Actually… One Developer Is Not Automatically the Scary Option

One of the laziest shortcuts in conversations about AI development is treating these three people as if they are interchangeable:

• an experienced independent developer
• a developer who uses AI as part of their workflow
• somebody who discovered an AI app builder on Tuesday and is now storing passport scans in a client onboarding portal

These are not the same person.

The original comment that inspired this series asked:

“How on Earth can a person relying on a solo dev or first-time vibe coder, with likely little to no ongoing monitoring, hope to even know when they’ve been breached?”

Notice how easily “solo developer” and “first-time vibe coder” are pushed into the same category, even though one is about team size and the other is about experience.

You can have one excellent developer who has spent years building and maintaining production software. You can also have a development agency with twelve people, a persuasive salesperson and no adult supervision anywhere near the code.

Team size is not a useful proxy for competence. Twelve people can still be wrong at once, although they do get considerably more meetings out of it.

A developer using AI is still a developer

An experienced developer does not lose their knowledge the moment they open an AI tool.

They still understand authentication, permissions, databases, APIs, testing, deployment, logs, backups and what can go horribly wrong when one part of the system trusts another part too much.

AI may help them write code faster, investigate an unfamiliar library, generate test cases or notice something they missed. Their experience is what allows them to judge whether the answer is useful, incomplete or complete nonsense.

A beginner might receive the same answer and assume it must be correct because it contains code, several comments and a sentence beginning with “Certainly!”

Both people can type the same prompt, but only one of them is equipped to notice when the response is plausible-looking rubbish.

I build software with AI. Pedro is a designer and I am trying to teach him better development practices, which gives me a live demonstration of this exact point.

Every so often, an AI or an influencer tells him something can be done. He takes that as sufficient evidence and goes to try it without me, so I usually discover the experiment afterwards.

Pedro is a very good designer. He is not yet a developer, and access to the same tools I use has not transferred my experience into his head.

Teaching him has involved more than one conversation beginning with, “Pedro, what did you change?”

That is why the label “vibe coder” becomes useless when it is applied to everyone who works with AI. The tool tells you almost nothing about the judgement of the person using it.

I get suspicious when someone needs a private consultation with ChatGPT before they can explain the system they supposedly built, because by then the expertise is being improvised in real time.

Headcount is not a security control

There are real advantages to having a larger team. More people can review the work, specialists can focus on infrastructure or security, and knowledge does not have to live inside one person’s head. Someone can be ill without the entire project entering a period of national mourning.

Those advantages matter, but they do not appear automatically because an agency has a crowded About page.

A large team is only useful if:

• responsibilities are clear
• somebody reviews the code
• security concerns reach someone qualified to assess them
• tests are actually written and run
• issues have an owner
• changes are documented
• people communicate with each other
• someone remains responsible after launch

Without those things, you have taken one potential point of failure and replaced it with a meeting.

The NIST Secure Software Development Framework describes practices for developing software securely. They include defining security requirements, protecting code, reviewing and analysing it, testing the software, using secure configurations and responding to vulnerabilities after release.

The framework explicitly says it can be used by organisations regardless of their size or cybersecurity sophistication. At no point does it say:

Step one: employ at least thirty developers.

Security comes from what people do, not how impressive the team photograph looks.

Large teams come with their own special nonsense

I have worked in AAA games, so I have seen large technical teams from the inside.

Those projects bring together huge numbers of talented people with specialised knowledge. They can build things one person could never hope to build alone.

They can also spend an alarming amount of time passing one bug between departments because it lives in the exact gap where nobody’s ownership begins.

One team builds the feature. Another owns the online services. A third handles authentication. QA can reproduce the problem, but only under conditions nobody else can reproduce. The person who understood the original decision has moved to another project or left the company.

Everybody involved may be perfectly competent, yet the overall situation is still a mess.

Large teams do not eliminate chaos. Sometimes they simply give it Jira tickets and invite it to a stand-up.

The same problems appear in ordinary software companies and agencies. More people can provide more oversight, but they also create more handoffs, accounts, permissions, systems and opportunities for everybody to assume somebody else checked it.

By the time the problem reaches the client, an account manager is assuring them that everything is “enterprise-grade” while nobody currently on the call knows why the database is accessible from the public internet.

Large organisations can build excellent software. They can also build extraordinarily complicated disasters with excellent project management dashboards.

CISA’s Secure by Demand guidance warns software buyers not to focus only on a company’s enterprise security measures and compliance standards. Buyers also need to examine the security of the actual product.

A company can have security policies, audits and hundreds of employees while one particular feature is still badly designed. Adding up all the people receiving salaries from the company will not repair it.

Sometimes one person understanding the whole system is useful

Small custom products do not always need an army.

When one experienced developer builds a focused application, they may understand the complete path through the system:

• where the data enters
• where it is validated
• where it is stored
• who can access it
• which external services receive it
• what gets logged
• what happens when something fails

With fewer handoffs, there are fewer places for responsibility to disappear.

When a problem appears, the person investigating it may be the same person who designed that part of the system. They do not need three meetings and an internal archaeology expedition before they can change it.

A smaller application may also have fewer moving parts, fewer permissions and a smaller attack surface. None of this makes it secure automatically, but it does make “more people” a poor substitute for examining the actual architecture.

Custom does not mean rebuilding the internet alone

A competent solo developer does not personally invent every security component. They use established services and libraries where that makes sense.

For example, I use Supabase Auth rather than waking up one morning and deciding that the world needs Ana’s Exciting New Password Algorithm.

A custom application might use:

• an established authentication provider
• a trusted payment processor
• managed database infrastructure
• monitored hosting
• automatic backups
• error tracking
• dependency scanning
• tested libraries for security-sensitive work

The developer remains responsible for configuring and integrating those services correctly.

Using them is not cheating. It is considerably more sensible than reinventing authentication, payments or encryption for the intellectual adventure of it.

NIST’s current secure-development guidance specifically recommends reusing existing, well-secured software when feasible.

A good developer knows which parts of a product should be custom and which parts absolutely should not be invented at 1 a.m. with help from an enthusiastic language model.

One developer does create real risks

There are legitimate concerns when one person builds and maintains an application, and pretending otherwise would be silly.

A solo developer may have blind spots. There may be no automatic second person reviewing their decisions. If the developer becomes unavailable, the business could struggle to maintain the product. Important knowledge can remain undocumented, and one person may not have deep expertise in every area the application touches.

These problems are usually described as key-person risk. They need to be managed, but their existence is not proof that the developer is incompetent.

A ten-person team can still have one person who understands the database, one who knows the deployment process and another whose laptop apparently contains the only working copy of something important.

The company invoice may say “team,” but the project can still be held hostage by Steve’s MacBook.

This is how you reduce the risk

The business should own or have appropriate access to:

• the source-code repository
• hosting and infrastructure accounts
• domains
• databases
• third-party services
• documentation
• backups
• deployment instructions
• recovery procedures

The system should not exist entirely inside the developer’s personal accounts.

Important architectural decisions should be documented, dependencies should be visible and there should be a clear handover path if somebody else needs to maintain the product.

Automated testing, dependency checks, monitoring and alerts can run regardless of whether the team contains one developer or one hundred.

Sensitive or high-risk applications should also receive independent review. OWASP explains that manual security review can identify problems automated tools miss, particularly issues involving business logic, permissions, authentication and data flow.

That does not require permanently hiring an enormous team. Another qualified developer or security specialist can be brought in at the stages where their expertise is needed.

Key-person risk is addressed through planning, documentation, access and appropriate outside review, not by adding fourteen people to every project so the proposal looks safer.

The level of scrutiny should match the risk

A private internal tool used by four employees does not need the same security process as an application storing medical records for thousands of people.

We covered this in the first post, and it remains true no matter how many developers are involved.

OWASP’s Application Security Verification Standard uses different levels of verification depending on how much assurance an application requires. Higher-value and higher-risk systems require deeper verification.

That is a much more useful way to think about security than counting developers.

If an application handles health information, payments, financial records, passwords or large amounts of personal data, one developer should not be the only person who ever examines its security.

I would say exactly the same thing about an agency.

If the agency has twenty developers but no independent security review, the twenty developers do not merge into one security specialist like a corporate Power Ranger.

Ask who is doing the work

Before hiring a solo developer or an agency, ask:

• Who will actually build the application?
• What relevant systems have they built before?
• Can they explain the architecture in language you understand?
• How will authentication and permissions work?
• Which parts will use managed services?
• What testing will be performed?
• How will errors and suspicious activity be monitored?
• Who receives alerts?
• How are backups created and restored?
• Who owns the accounts and source code?
• What happens if the original developer becomes unavailable?
• Does the project need an independent security review?
• Who maintains the product after launch?

Do not be distracted by the number of people introduced during the sales call. Some of them may never go near your project again.

I would rather work with one developer who can explain every important decision than an agency where the salesperson says “enterprise-grade” and nobody can tell me who configured the database.

One developer is not automatically the dangerous choice

There are projects where one developer is plainly not enough. A large, complicated or highly sensitive system may require several engineering disciplines, independent security expertise, continuous operational coverage and more capacity than one person can provide.

That decision should be based on the product and its risks, not a universal belief that custom software becomes safe when enough people are added to the Slack workspace.

An experienced solo developer with good processes, appropriate tools, managed services, clear documentation and independent review can outperform a much larger team with poor processes.

Judge the work, the decisions and the safeguards.

Count the controls, not the LinkedIn profiles.