Can You Vibe Code a Startup? What AI Builds and What It Can't

If you are wondering whether you can vibe code a startup, the honest answer has two parts. You can vibe code a working prototype in days, and for testing an idea that is often all the first version needs. You usually cannot vibe code the company, because an app that looks finished is a long way from software that real customers, payments and personal data can rely on.

Product was always the hard part: knowing who it is for, what to build first and why they would pay. Code has become the cheap part. This article covers what vibe coding does well, where it falls short, what the security research says and how to decide when to bring in engineers. If you already have an AI-built app that is straining, our vibe code rescue service starts with a fixed £3,000 audit.

Key takeaways

• Vibe coding is a fast, cheap way to test an idea with a working prototype. It does not tell you what to build or who it is for.
• The gaps appear when real people depend on the app: security, a sound data model, tests, backups and someone who understands the code when it breaks.
• Security research on AI-generated code keeps finding flaws, so anything that handles logins, payments or personal data needs a human review before launch.
• You often do not need a developer for the first version. You usually do before real customers, payments or personal data.
• Treat the prototype as a test. Then decide on purpose whether to harden it, rebuild it or stop.

What is vibe coding, and can anyone do it?

Vibe coding is building software by describing what you want in plain English and letting an AI tool write the code. The term comes from the AI researcher Andrej Karpathy, who used it in a post on X in February 2025. He described a way of working where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists” (Andrej Karpathy on X, 2 February 2025).

It spread quickly. Collins Dictionary named it Word of the Year for 2025. It defines the term as “the use of artificial intelligence prompted by natural language to assist with the writing of computer code” (Collins Dictionary).

In practice it covers a range. At one end, someone with no coding background describes an app to a builder such as Lovable, Bolt or Replit and accepts what comes back. At the other end, an experienced developer uses an AI assistant and reads every line. This article is about the first end, where nobody reads the code, because that is where the startup question gets hard.

Can anyone do vibe coding?

Yes, for a first prototype. You describe the app, the tool builds it, you look at the result and you ask for changes. You need no programming knowledge to get something on screen. That is a real change, and it means founders can test an idea before spending anything on development.

What the tool does not give you is the ability to judge what it produced. Y Combinator is a useful example. In March 2025 its managing partner Jared Friedman said a quarter of the Winter 2025 batch had codebases that were 95% generated by AI (TechCrunch). He also made clear these were not newcomers, saying “Every one of these people is highly technical, completely capable of building their own products from scratch”.

That is the pattern to notice. People who can read code use AI to go faster, and they can tell when it has gone wrong. People who cannot read code have no way to check whether what they were given is sound.

Professionals are cautious too. Stack Overflow’s 2025 developer survey asked whether vibe coding is part of professional development work. Its summary: “Most respondents are not vibe coding (72%), and an additional 5% are emphatic it not being part of their development workflow” (Stack Overflow). The same survey found more developers actively distrust the accuracy of AI tools (46%) than trust it (33%).

What can you build by vibe coding?

The useful question is what happens if the app is wrong. If the answer is “nothing much”, vibe code it. If the answer involves someone’s money or data, bring in engineers. The table sorts common projects by that test. It reflects our judgement and is not a published standard.

Fit	Examples	Why
Good fit	Clickable demo for user interviews	Nothing is lost if it breaks
Good fit	A tool only your team uses	Few users, easy to replace
Good fit	A simple landing page	Little logic to get wrong
Risky	An app with customer logins	Access rules are easy to get wrong
Risky	Anything storing personal data	Exposure costs trust and may cost more
Needs engineers	Payments, billing and refunds	Mistakes cost money directly
Needs engineers	Core systems and heavy growth	Design choices are hard to undo

A prototype is most useful when it answers a question before you spend serious money. Our work on Fix My House is a high-fidelity interactive prototype delivered in weeks, built to validate the idea with users and investors before funding development. Whether you make a prototype with a designer or an AI tool, the job is the same: learn before you commit.

Why vibe coding is risky for a real product

Vibe coding is fine for what it is good at. The trouble starts when a prototype is treated as a product. Six things sit between the two, and a demo does not need any of them.

Deciding what to build. The tool builds whatever you ask for. It cannot tell you whether anyone wants it, which feature matters first or what to leave out. That is product work, and it is where most startups succeed or fail. A product discovery sprint exists for exactly this.

A sound data model. How information is organised underneath, such as customers, orders and permissions, decides whether you can add the next feature without breaking the last. A demo can get away with a structure that fails at the first awkward case.

Authentication and security. Who can log in, who can see whose data and who can change what. This is where the research below is clearest.

Testing. A demo only has to work once, in front of you. A product has to keep working after every change. Automated tests are what catch the edit that quietly breaks last month’s feature.

Scale and running costs. An app that works for you and ten friends can behave differently with thousands of users. Hosting, database load and per-use fees from third-party services all grow with usage, and a demo tells you nothing about them.

Maintenance and someone who understands the code. When the app breaks at a bad moment, someone has to read the code, find the fault and fix it without breaking something else. If nobody on your team has read it, that person does not exist yet. Y Combinator’s CEO Garry Tan added in the same piece that “The first versions of reasoning models are not good at debugging”. That was March 2025 and models change quickly, so treat it as a dated observation. The point that lasts is that fixing code you did not write and have not read is slower than fixing code you understand.

What does the security research say?

Security is where the evidence is clearest. The studies disagree on size but agree on direction.

Veracode’s 2025 GenAI Code Security Report analysed code from over 100 large language models across Java, JavaScript, Python and C#. Its headline result: “AI-generated code introduced risky security flaws in 45% of tests.” Veracode also reported that larger, newer models did not improve security (Veracode).

Tenzai, a security company, tested five AI coding agents (Cursor, Claude Code, OpenAI Codex, Replit and Devin) in December 2025, giving each the same prompts to build identical applications. Across the 15 applications it found a total of 69 vulnerabilities (Tenzai). Two details are worth knowing.

First, the tools avoided the textbook flaws. Tenzai wrote that across all the applications it developed, it did not encounter a single exploitable SQL injection or cross-site scripting vulnerability. Second, Tenzai reported that the agents did poorly at enforcing authorisation and were prone to business logic flaws, which decide who is allowed to do what. Those depend on knowing how your business should work, so a tool cannot simply copy them from a pattern. That interpretation is our own.

Neither study measures your app, and the tools improve quickly. Read them as a guide to where to look. They are not a failure rate you should expect.

If your app holds personal data, UK law sets the test. The ICO’s guide to data security says the UK GDPR “requires you to have a level of security that is ‘appropriate’ to the risks presented by your processing” (ICO). The ICO notes that its guidance is under review following the Data (Use and Access) Act and may change, and this is not legal advice. What it means in practice is that a login system and a customer list deserve more than a prototype’s defaults. Someone has to decide what “appropriate” means for your app and check that it is true.

Is vibe coding better than coding?

It is a different tool, and for some jobs it is better. For exploring an idea quickly and cheaply it wins, which is why it is so popular. For building something that must run for years, the work that remains is engineering: design decisions, review, testing and operating the product. That work is the same with or without AI helping.

The survey figures above fit this. Most developers who answered said they do not vibe code at work, and for shipped software that seems sensible to us. The skill that matters is knowing whether the code is right.

Do you still need a developer in 2026?

Often not for the first version. If your goal is to interview users, show investors or test whether anyone cares, a vibe-coded prototype does the job. Paying a studio for that first version can be money wasted, and we would rather tell you so than sell you a build you do not need yet.

Usually yes before real customers, payments or personal data. At that point you need someone accountable for the code. That does not have to be a technical co-founder on day one. A co-founder is a great answer if you can find one who believes in the idea, but finding one is slow and you do not need one to test. The other routes are a first hire, a fractional CTO or a studio. Which fits depends on how long you will run the product and how much of its direction you want to own.

If you have not yet decided what the first real version should contain, our guide to how to build an MVP walks through it. The difference between a proof of concept, a prototype and an MVP is set out in our comparison.

A checklist before real users arrive

Answer these about your app. Each “no” or “I don’t know” is a reason to get the code reviewed first.

1. Have you spoken to the first ten people who would pay, and do you know what they would pay for?
2. Can you explain in plain words how users log in and who can see whose data?
3. Has anyone tried to reach another user’s record by changing the address or the request?
4. If it holds personal data or takes payments, has a person decided what security is appropriate?
5. Is the code in a repository you control, and have you tested restoring the database from a backup?
6. Are there automated tests for the most important flows?
7. When it breaks on a Friday evening, who fixes it, and can they read the code?
8. Do you know roughly what it would cost to run at ten times today’s usage?

A few “no” answers on a personal tool or a demo do not matter. The same answers on an app with paying customers do.

What it costs to take a prototype further

Our prices are fixed and agreed before work starts. Your AI tool subscription is billed by its provider, separately from any work with us.

Route	Fits when	Our price
Keep it as a prototype	Only you and testers use it	Nothing from us
Rescue audit, one week	Real users are coming	£3,000
Rescue build, audit to production	The audit says save or part-rebuild	From £8,000
Discovery sprint, 1–2 weeks	The product is untested	From £4,000
MVP build	A clean build beats saving the code	From £15,000

The rescue audit reviews security, authentication and the data model, assesses architecture and test coverage on your real codebase, and ends with a go, save or rebuild verdict. It is a fixed £3,000 with no obligation to continue. The rescue build starts from £8,000 and hardens the code worth keeping, rebuilds the risky parts, adds authentication, automated tests and monitoring, and ships to production. Sometimes a clean rebuild is faster and cheaper, and the audit says so.

If the product itself is untested, start earlier. A discovery sprint starts from £4,000 and defines the smallest useful product. For a clean build, MVP development starts from £15,000.

A first real version can also be lean. Our Simple PT work was a deliberately lean MVP on a tight budget, with a booking-and-payments app live on both app stores two months from kick-off. If you go on to a build with us, scope and price are fixed first and you pay by milestone as each stage is delivered. On an MVP build, you can cancel within the first 21 days and get your money back in full. All code and IP are yours once the work is delivered and paid for.

Your next step

Run the checklist above this week and write down your answers. If real users are waiting, or the answers worry you, book a vibe code rescue audit. A week and £3,000 buys you a clear verdict on whether to keep the app, fix it or replace it. If you have not yet tested the product with customers, start with discovery instead and keep the prototype as a test.