A woman who has never written a line of code types a paragraph into an editor after her kids are asleep. It describes a tiny tool her book club keeps wishing for. By midnight it works. A week later, three strangers are paying for it.
Now look at your own evenings. Maybe you sit at a desk job that feels thinner every month, watching AI quietly absorb the tasks you were hired for. Maybe the mortgage reset and the numbers stopped working. The friends who used to complain about work with you have started talking about their side projects instead.
The same AI that threatens ordinary office work is what lets you build software alone. And the crowd has noticed. Lovable alone produced 10M+ projects, so the shelves are filling and being found gets harder every month. Builders who start now learn while the field is still finding its feet. Those who start later walk into a louder room.
Getting in costs between $0 and $100: a code assistant at around $10 a month, and hosting that starts with a $5 credit. Months 1 to 3 are usually your learning phase, first revenue tends to land somewhere in months 3 to 6, and a working month at the low end is about $1,000.
Tonight, pick one annoyance from your own week and write the fix as a single paragraph of plain English. That paragraph is your first prompt.
Sit with what that means for you for a moment. Building software used to take years of computer science education, internships and professional experience. Now you can do a good deal of it with a clear idea and the patience to keep trying. The barrier to starting a software business has never been lower, and you are standing right at it.
The traditional road into software goes like this: you learn a programming language, understand data structures and algorithms, study frameworks, build projects, and slowly develop the expertise to create production applications. That usually takes three to five years of dedicated study and practice.
Vibe coding shortens that road dramatically. You skip memorising syntax and function calls, and you describe what you want in plain English. AI coding assistants like Cursor, Claude and GitHub Copilot turn your descriptions into working code. You review the output, give feedback, and keep going until the application matches what you had in mind.
Programmers still matter, and so does a computer science education. What vibe coding does is widen the circle of people who get to build. If you are a product manager, you can now prototype your own ideas. If you are a designer, you can build working versions of your mockups. If you have a business idea, you can test it before hiring anyone.
Here is the shift in one line. Traditional coding asks you to learn the language computers speak. Vibe coding lets computers learn the language you already speak.
You have several ways to earn from this, each with its own risk and its own ceiling.
Which of these five fits the hours you actually have? If your evenings are short and broken up, an extension or a template is gentler on you than a client with a deadline.
One client project priced at 2,000, the bottom of the 2,000 to 20,000 per project band described here, is a meaningful sum for most households. Ship one small MVP for a local business and the profit could cover a term of after school clubs for your kids. Start with a project you can test, finish and hand over.
That is the shape of the thing. What follows is the order you do it in, starting from an empty screen and nothing installed.
Start by signing up for Cursor, the AI-powered code editor that has become the standard tool for vibe coding. The subscription costs $20 monthly, a small outlay next to what it can return. Install it and spend some time getting to know the interface.
Next, create your accounts on Vercel (for deployment), Supabase (for database and authentication) and GitHub (for version control). All of them have generous free tiers that will carry your first projects at no cost.
Build something simple in your first week. A landing page is ideal. Tell Cursor what you want: "Create a landing page for a productivity app with a hero section, feature list, testimonial carousel, and email signup form." Watch the AI generate the code. Deploy it to Vercel with a single click. You have just shipped your first vibe-coded project, and it is a good feeling. Let yourself enjoy it.
Spend this week learning patterns. Look at successful indie hacker products on ProductHunt and IndieHackers and notice what they do well. You will see the same things again and again: a clear promise, a simple interface, a narrow focus.
Build something a little more complex. A calculator, a tool that converts something, or a basic game. Practise the loop: describe what you want, review the output, sharpen your description, try again. You are training yourself to talk clearly to the AI, and that is the central skill here.
Read through the code the AI writes for you. You do not need to understand every line, but a rough sense of how applications are put together will help you guide it better. Once you know that "components" are reusable pieces, "state" tracks what changes, and "APIs" connect to outside services, you have the vocabulary for sharper requests.
Pick a problem you personally have. The best products come from real frustration with what already exists. Your problem does not need to be unique or revolutionary. A small improvement on an existing tool can do better than a novel idea, because someone has already proved people pay for it. What annoyed you three times this week that a small app could fix?
Write a detailed product description in plain English. Describe every feature you want. Sketch the screens on paper or in a design tool. The clearer your picture, the better the AI can build it.
Start building in Cursor. Work one feature at a time and test as you go. Connect Supabase for anything that needs storing. The AI can walk you through database setup, authentication and API creation.
Finish the core functionality and get ready to launch. Make a polished landing page explaining your product. Set up payment processing with Stripe if you are charging from day one.
Launch on Twitter, ProductHunt or the community forums where your users already hang out. Share honestly, explain the problem you are solving, and ask for feedback. Your first users will tell you what works and what needs fixing.
Write down what you learned: what worked well when you talked to the AI, and which features were harder than you expected. Those notes make your next project faster.
So you know how to get a first version running. The next question is when any of it starts paying you, and how much.
If the first three months bring in $0, could you keep showing up anyway? Most people who quit do it right here, a few weeks before their first paying customer.
Picture the first month a small app pays for itself and then some. It covers the streaming subscriptions, then the car payment, then a weekend away booked without checking the account first. Each app that sticks is income your employer never had to approve.
Add it up and you can start on $40 a month, or less if you lean on the free tiers. What is one month of that worth to you if it gets your first product live?
Mistake 1: Building Without Validation It is easy to get excited that you can build and forget to check whether anyone wants it. What to do: before you write any code, show your idea to the people you hope will use it. Pre-sell if you can. A Stripe payment is the strongest proof there is.
Mistake 2: Over-Engineering Early The AI can build complex features, and that is exactly the temptation. Adding authentication, payment processing, admin dashboards and analytics before you have a single user burns your evenings on things that may never matter. What to do: build the simplest version that delivers the core value. Add complexity only when your users ask for it.
Mistake 3: Ignoring the Code Vibe coding still asks you to know roughly what is being generated. Accepting AI output blindly leads to security holes, slow apps and bugs. What to do: learn enough to review code with a critical eye. You do not need to write it, but you should spot obvious problems.
Mistake 4: Giving Up After One Failed Product The odds of your first product succeeding are low. That is true for traditional developers too. Most successful indie hackers failed several times before something worked. What to do: treat early projects as practice. Your skills build on each other, and each attempt has a better chance than the last.
Mistake 5: Neglecting Marketing "Build it and they will come" has never been true. A mediocre product with great marketing beats a great product with none. What to do: spend at least as much time on getting the word out as on building. Build in public on Twitter. Write about your journey. Grow your marketing skills alongside your coding skills.
Mistake 6: Underpricing When you are new, it is tempting to price low out of imposter syndrome or fear of hearing no. Charging $5/month for something genuinely useful leaves money on the table and attracts the wrong customers. What to do: look at what competitors charge. Start at a price that feels slightly uncomfortable. You can always discount later, and raising prices is much harder.
Be honest with yourself about which of these six you are most likely to make. For most people it is number five: building is fun, and telling strangers about it feels exposing.
What the people who make it do differently
Speed of execution: The vibe coders who succeed ship fast and often. They accept imperfection and improve from real feedback. Overthinking kills more products than bad code does.
Problem selection: Solving a real problem for a specific audience beats building a clever solution in search of a problem. The best products are painkillers, the ones people reach for when something hurts.
Distribution thinking: Successful builders work out how people will find the product before they build it. They pick niches where they can already reach potential customers.
Persistence: Building in public means failing in public. The ones who last grow a thick skin and keep shipping. One breakout hit makes up for many misses.
Continuous learning: AI tools change fast. What works today may be obsolete in six months. The best builders keep up with new models, features and techniques.
Community engagement: The indie hacker community is generous with what it knows. Showing up genuinely, helping others and building real relationships brings you opportunities, feedback and support.
Who do you already know who has the problem you want to solve? If you can name three people, you have your first distribution channel.
The risks, plainly
Financial Risk: Low Your startup costs run $0-100/month. You can test ideas before spending much. The main cost is your time, and what else you could have done with it.
Skill Obsolescence Risk: Medium AI capabilities change fast. Skills that feel valuable today may be automated further tomorrow. What helps: put your energy into product thinking and understanding customers, alongside the technical side.
Market Saturation Risk: Medium As vibe coding gets easier, more people compete. Generic products get squeezed. What helps: choose niches, build real knowledge of one field, and build a brand people remember on top of your products.
Technical Debt Risk: Medium AI-generated code can pile up problems that grow over time. Without traditional engineering knowledge, fixing deep issues gets hard. What helps: keep products simple, clean up regularly, and consider paying for technical help as a product grows.
Burnout Risk: Medium The pressure to keep shipping, plus the loneliness of building alone, wears some people down. What helps: set a pace you can keep, stay connected to other builders, and celebrate small wins.
Where you go from here
Vibe coding has changed what is possible if you want to build software on your own. The tools will keep improving and the barrier will keep dropping. What matters now is whether you use this moment.
Start this week. Sign up for Cursor. Build something small. Ship it. Learn from it. Repeat. The vibe coders who do well over the next decade are starting now.
Your first product probably will not succeed. That is fine. Neither did the first products of most successful indie hackers. What matters is that you start, keep learning, and keep going through the failures that are coming.
The opportunity is real and the tools are ready. The only open question is whether you will begin.
Talking to the AI so it builds what you mean
How you talk to the AI is the most important skill you will build here. The gap between a frustrating, broken result and a feature that just works usually comes down to how you framed the request.
The CRISP Framework
Use the CRISP framework when you ask for something complex:
Context: Explain your existing codebase, tech stack and what is already built. Point to specific files or patterns you already use.
Requirements: Say clearly what the feature should do. Include edge cases and how you want errors handled.
Interface: Describe how your users will interact with it. What do they see? What do they click? What feedback do they get?
Specifications: Add technical details like data structures, API endpoints or database schemas if they matter.
Patterns: Point to similar code in your project, or well-known patterns you want followed.
Iterative Refinement
Vibe coding works best as a back-and-forth conversation. Start with a high-level request, review what comes back, then refine with specific feedback. Each round should fix specific issues; asking for everything to be redone usually makes things worse.
Here is how a conversation might go:
- "Build a user settings page with profile editing and notification preferences"
- "The form should include validation for email format and required fields"
- "Add a success toast notification when settings are saved"
- "The notification preferences should be toggles, not checkboxes"
Working step by step like this gets you better results than trying to specify everything up front.
Debugging Conversations
When something breaks, describe the problem in order:
- What you expected to happen
- What actually happened
- Any error messages you see
- The steps to reproduce it
Ask the AI to explain its reasoning before it proposes a fix. Once you understand why something broke, you stop making the same mistake.
Think back to the last thing you asked an AI to build. Did you give it context, or just the wish? Adding two sentences of context is often the whole difference.
Choices that are cheap now and expensive later
Optimising too early is a mistake, but a few architectural decisions get expensive to change later. Get these right from the start:
Separate concerns: Keep your business logic apart from your UI components. Future changes and testing get much easier.
Environment configuration: Use environment variables for anything that differs between development and production (API keys, URLs, feature flags).
Database migrations: Use proper migration tools from the beginning. Manual database changes become unmanageable fast.
Error handling: Handle errors the same way everywhere. Your users should see friendly messages; you should see detailed logs.
Authentication patterns: Get authentication right early. Bolting auth onto an existing application later is painful and error-prone.
How you get paid
Now that you have something people will actually open, the decision changes. What follows is how the money gets collected and who you collect it from.
Knowing a little pricing psychology helps you earn more from the same product.
Pricing strategies
Value-based pricing: Price on the value you create for your customers rather than on your costs. If your tool saves someone 10 hours per month, $50/month is reasonable even if it cost you nothing to build.
Tier structure: Offer 3-4 tiers. The bottom tier catches price-sensitive users. The middle tier suits most customers. The top tier is for people happy to pay a premium for extra features or limits.
Annual discounts: Offer a 15-20% discount for paying a year up front. Your cash flow improves and fewer people cancel.
Grandfathering: When you raise prices, keep existing customers on their original rate. They stay loyal and churn drops, while new customers pay the new price.
How many hours a month does your idea save the person using it? Multiply that by what their hour is worth to them, and you have a better starting price than whatever feels polite.
Revenue optimization
Churn reduction: Reducing churn by 5% can increase lifetime value by 25-95%. Put your effort into onboarding, engagement, and the reasons people give when they cancel.
Expansion revenue: Selling more to existing customers is easier than finding new ones. Build natural upgrade paths into your product.
Payment recovery: Failed payments are a big source of accidental cancellations. Use dunning tools to retry failed payments automatically and let customers know.
Friends notice when a product you built starts paying its own way. If subscriptions settle around 1,000 a month, the first figure in this page's range, the colleague who smiled at your side project may ask over coffee how you found your first customers. Follow up on failed payments so you know how much of that revenue actually reaches your account.
Finding your people
The indie hacker community is unusually collaborative. Time you put into relationships comes back as feedback, opportunities and support.
Building your network
Twitter/X: The main platform for indie hackers. Share your journey, talk to others, and give before you ask for anything.
IndieHackers.com: The dedicated home for indie founders. Join discussions, share your milestones, and learn from other people's experience.
Discord servers: Many niche communities have busy Discord servers where you can meet potential users and fellow builders.
Local meetups: In-person connections often matter more than online ones. Go to startup events, hackathons and coworking spaces.
Building in public
Sharing your journey publicly gives you accountability, feedback and marketing all at once. Write about what you are building, what you are learning and what is hard. People respond to honesty more than polish.
Playing the long game
Success here rarely happens overnight. The builders with significant results typically spend 2-3 years developing skills, shipping products and adjusting to what the market tells them. Reputation, skills and a handful of products build on each other, and that takes time.
Set realistic expectations. Celebrate small wins. Remember why you started. The journey has value of its own, whatever the destination turns out to be. Could you see yourself still doing this two years from now, on the weeks when nothing sells?
Keeping your apps running
As your projects grow, running them well matters more and more.
Monitoring and alerting: Set things up so you hear about breakages before your users do. Use services like Sentry for error tracking, UptimeRobot for availability, and custom alerts for business numbers. Catching problems early keeps small issues small.
Database management: Learn database basics even if you use a managed service. Know when to use indexes, how to write efficient queries, and when caching makes sense. The database is often where an app slows down as it grows.
Security hygiene: Follow security best practices from day one. Use parameterized queries to prevent SQL injection. Sanitize user inputs. Keep dependencies updated. Implement proper authentication and authorization. A security hole can sink a business overnight.
Cost optimization: Cloud costs can spiral without warning. Understand how the services you use charge you. Set up billing alerts. Keep an eye on efficiency as you grow. Plenty of indie hackers have opened a bill bigger than their revenue.
Backup and recovery: Set up automated backups from day one. Test that you can actually restore them every so often. Losing your users' data can destroy their trust for good. Good backups pay for themselves the first time something goes wrong.
If your hosting bill doubled next month, would you find out from an alert or from your bank statement? Set the billing alert today; it takes five minutes.
2026 Market Snapshot
Vibe coding (building shippable software faster than the idea cycle, often with AI tooling) has become the main way indie hackers work in 2026. Independent market research maps the opportunity through three overlapping reports: micro-app portfolios with documented 5% hit rates, AI coding assistants now scaling to multi-million ARR, and build-in-public as the standard way to get noticed. If you are working alone, the numbers favour a portfolio of small bets over one big one.
- Portfolio leader benchmark: Pieter Levels runs 70+ projects with a ~5% hit rate, generating $3.1M ARR with zero employees
- Top-product revenue from one operator: Levels' PhotoAI does $132,000/month, RemoteOK $41,000/month, InteriorAI $38,000/month
- Multi-product solo operator: Marc Lou launched 23 projects before ShipFast hit; 2025 earnings $1.03M
- AI build-tool scale: Cursor at $1B+ ARR with $29.3B valuation, Lovable at $100M ARR in 8 months, Bolt.new at $40M ARR in 6 months
- AI coding assistant ceiling: Allan Mørch grew AskCodi to $5,000,000 ARR
Look at that 5% hit rate again. Out of 70+ projects, only a handful carried the rest. How many small launches could you realistically make this year, knowing most will go quiet?
Key Players to Watch
These are self-published or publicly reported figures rather than audited ones. Most are annual recurring revenue, which is a run-rate projection rather than money received, so read them as direction of travel.
The vibe-coding world in 2026 includes portfolio builders, AI build platforms, AI coding assistants, and the build-in-public community that spreads the word.
- Pieter Levels: 70+ project portfolio, $3.1M ARR solo (PhotoAI, RemoteOK, InteriorAI)
- Danny Postma: HeadshotPro $300K year one; portfolio includes TattoosAI, StockAI, Deep Agency
- Marc Lou: ShipFast + CodeFast (~$20K/mo each), DataFast at $15.8K MRR with 14% MoM growth
- Tony Dinh: TypingMind ($130-160K/mo); sold BlackMagic.so for $128,000
- Erikas Malisauskas: Shopify-app portfolio at $4.5M/year, ~90% margins
- Cursor: AI code editor; 1M+ DAU, $1B+ ARR
- Lovable / Bolt.new: fullstack AI app builders; Lovable at 10M+ projects, Bolt at 5M signups
- GitHub Copilot / Tabnine / Codeium / Sourcegraph Cody: AI coding assistants
- Devin (Cognition AI): autonomous AI software engineer running Upwork tasks
- Replit AI: $20/month full-stack AI dev environment
- ShipFast: Next.js boilerplate at $130K+/mo, used by 7,200+ developers
- Acquire.com / Flippa / Empire Flippers: exit marketplaces ($50K-$10M+ deals)
- the operator / Arvid Kahl / Damon Chen / Brett Williams: build-in-public builders worth following
Predictions for 2026-2027
- Portfolio founders outearn single-product founders at the median as well as at the top. AI tooling makes launching a new app cheaper than rescuing a failing one, so the "ship 20, keep the 1" math compounds.
- A "portfolio OS" category emerges: unified billing, analytics, support and authentication across multiple apps. Independent market research explicitly calls out this gap; expect $49-$199/mo SaaS solutions and acquisitions by ChartMogul or Paddle.
- Vibe-coded apps trigger a distribution crisis. Lovable alone produced 10M+ projects; supply floods, and being found becomes the moat. Builders with audiences (Levels' 800K+ Twitter followers, Marc Lou's newsletter) take a disproportionate share.
- AI-powered app maintenance becomes a productized service ($20-$50 per app per month). Solo builders with 15-app portfolios outsource maintenance for $300-$750/mo and win back their build time.
- More agent-driven coding work moves to Devin-style autonomous engineers. Solo builders hand test writing, dependency upgrades and bug fixes to agents and spend their own time on distribution.
Read the line about distribution twice. Supply is flooding in, and builders with audiences take a bigger share each month. Start building your app and your audience together this year and you get to be early in a few small corners. Wait a year and those corners fill with people who began while you were still deciding.
Emerging Opportunities
Portfolio operating system: Connect Stripe, Plausible/PostHog and hosting providers into one dashboard. Independent market research lists this as open white space; price at $49-$199/month based on connected apps. Solo builders are obvious early customers, and you may be one of them.
Distribution-as-a-service: Max Huang credits ASO optimization with a 50% boost on portfolio metrics. You could bundle ASO, programmatic SEO and changelog newsletters into a fixed monthly retainer for builders who can build but can't market.
AI app-maintenance service: Combine Claude Code, GitHub Copilot and Dependabot into a managed-maintenance offer. Charge $20-$50/app/month; a 15-app portfolio is $300-$750 MRR per client, and your clients can see the saving next to rebuilding.
Niche AI coding assistant: CodeWP for WordPress shows how a vertical coding assistant works. A WordPress, Shopify or Webflow assistant has a structural moat (its tuning data) over general-purpose alternatives.
Build-in-public lead-gen funnel: Brett Williams built Designjoy to $1M solo by sharing the journey; Karthik Sridharan grew Flexiple and buildd to $3M ARR documenting the process. In 2026 this is the cheapest way for you to get a product in front of people.
Building in public has a long tail. Should a small portfolio of products hold well above the 1,000 a month floor for a year, with profit after costs covering your home expenses and a few months of runway saved, leaving your job becomes a date you can schedule. Results at the top of the range are rare, and a modest product that keeps paying is the realistic target. What would those few months of runway let you say yes to?
Common Objections & Counterarguments
"Vibe-coded apps are a race to the bottom.": Building has become cheap; only distribution, brand and data remain defensible, in Independent market research's exact framing. Builders with audiences and tuning data still charge premium prices even when the underlying app is "easy" to clone.
"You're building a graveyard of half-finished products.": That is the design. 95% of the portfolio is dead weight by definition; the strategy is making the math work on the 5% that hit. The 5% hit rate is documented across builders (Levels 70+, Marc Lou 23). It works because of volume.
"Platform risk is concentrated, not diversified.": True. Apple, Google, Stripe and hosting providers can freeze your whole portfolio with one policy change. The protection is owning your email list, your audience, and at least one direct-payment route across the portfolio.
Where the term came from, and why it matters to you
The phrase has a precise origin, and knowing it settles most of the arguments you will hear about what vibe coding is.
Andrej Karpathy coined it in February 2025. The OpenAI co-founder described a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists". By March 2025 Merriam-Webster had listed it as a slang and trending expression, and in November 2025 Collins English Dictionary named it Word of the Year, defining it as the art of making an app or website by describing it to artificial intelligence rather than writing programming code manually. Alex Beecroft, Collins' managing director, said the term "perfectly captures how language is evolving alongside technology".
Two things about that origin are worth keeping in mind, because both get lost when the term is used as a marketing label.
It described an attitude. Karpathy was talking about forgetting the code exists. He meant a way of working, deliberately loose, for throwaway and exploratory projects. He never claimed you could stop reviewing code for software people rely on.
The caveat was there from the beginning. Reporting on the Collins award noted plainly that the practice is imperfect, with no guarantee the code will actually work or be free of bugs, and that more complicated tools still require skill. The honest version of vibe coding has always carried that warning. The version sold in courses usually drops it. If someone is selling you a course, ask yourself which version you are being sold.
What really changed, and what stayed hard
It helps you to separate the real shift from the story told about it.
What genuinely changed is the cost of the first working version. Getting to something that runs, that you can click through and react to, went from days to minutes. That makes being wrong about an idea far cheaper, which is a real and large change in how software gets started. It also opened building to people who had the domain knowledge and the customers but never the syntax. If that describes you, you are in the group where a lot of the good work is coming from.
What stayed the same is everything after the first version. Auth that holds. Data you can migrate. Errors that surface instead of vanishing. Behaviour when many users arrive at once. A bill that grows slower than your usage. Somebody who can work out what failed at 2am. Generation has compressed the beginning of the work and left the middle and the end roughly where they were, which is why the gap between a demo and a product feels wider now than it did five years ago rather than narrower.
That gap is the whole business opportunity, and it is also the trap. The people making money here are the ones who can carry something from the generated draft through to a system that survives real users, and who charge for that second part. Generating fast is the easy half. Could you be the person who answers the phone at 2am when something breaks, or would you rather sell the version that never needs that?
What this means for what you sell
Three practical consequences follow for you.
Prototypes and production are different products with different prices. A generated prototype is genuinely worth something to a client deciding whether to fund a project, and it is a legitimate thing to charge for. Selling it as production software is where your reputation gets damaged, because the failure shows up months later on someone else's watch and traces back to you.
Read what you ship. The line between vibe coding and professional practice is whether anyone understood the code before it went live, whoever or whatever wrote it. You do not need to have typed it. You need to be able to explain what it does, what happens when it fails, and where the data goes.
Expect the tools to keep absorbing the easy half. Every new generation of these tools takes over more of the work that used to be billable. If you sell yourself on speed of generation, you are competing directly with the thing improving fastest. If you sell yourself on judgement, integration and being accountable for the result, you are competing with something that improves far more slowly.
The term was coined in February 2025 and is already in the dictionary. Read that as a sign of how much attention it has, rather than how mature it is, and price your work with that in mind.
The security settings nobody asks for
Shipping this fast has a bill attached, and here is where it comes due. The settings you never thought to ask about are the ones that decide whether your app can safely hold anyone else's data.
The most expensive failures in generated apps are the ones you cannot see: the things the model never had a reason to add, because you never asked and the code runs fine without them.
A model completes the request you made. If you asked it to "build me a booking app", you will get something that books things. It may never check that the person cancelling a booking is the person who made it, because nothing in your prompt raised the question and the demo works perfectly without it.
The same gaps turn up often enough to check as a list.
Authorisation as distinct from authentication. Generated apps usually handle logging in. They often fail to check, on each operation, that this particular user is allowed to act on this particular record. The app works perfectly in testing, because you test as one user at a time.
Keys on the client. An API key placed in front-end code is visible to anyone who opens the browser tools, and it is billed to you. This is one of the most common and most costly single mistakes, because the meter runs until someone notices.
Inputs that reach a database or a shell unescaped. Modern libraries make the safe path the default and generated code often takes it. Often falls short of always, and the unsafe version looks identical until someone exploits it.
Uploads with no limits. File type, size and destination all need limits, and a generated upload handler frequently has none.
Errors that leak internals. Stack traces and database messages sent back to the browser are a map of your system, and the default setting in development is to show them.
Dependencies nobody chose. Generated code imports packages. Those packages have versions, vulnerabilities and maintainers, and nobody has looked at any of it.
You can still build this way. What it asks of you is a review pass with a specific checklist, which takes an hour and turns a liability into a deliverable. If you cannot do that pass yourself, it is worth knowing before you take anyone's money, and it is a reasonable thing to pay someone else to do. If a client's customer data leaked through your app next month, could you say exactly which of these six you had checked?
What to do about it
Run every build through the same short sequence before it goes anywhere near real users or real data.
Ask explicitly for the things you did not ask for. "Add authorisation checks so a user can only read and modify their own records" is a prompt, and it works. So is "move every secret to server-side environment variables and list what you moved."
Test as a second user. Create two accounts and try to reach the first account's data from the second, by changing an identifier in the URL if nothing else. This one test catches the single most common serious flaw.
Check what is in the browser. Open the network tab and the page source and look for anything that resembles a key or a token. It takes you two minutes.
Turn off detailed errors before launch, and confirm it by triggering one.
And keep a written note of what you checked. If your client later asks whether the application was reviewed, your answer needs to be more specific than yes. That note is also what lets you sleep the night after launch.
None of this needs a degree or anyone's permission. It needs one evening, one paragraph and the patience to run those checks before launch. Every month you put it off, your job shifts a little further under you and someone else ships the small tool you meant to build. Open the editor tonight and describe the first screen.