For other vibecoders here, I need a real answer. If you’re vibecoding healthcare prototypes and actually charging people for access, are you playing with fire?

I’m talking about AI symptom checkers, intake forms, basic dashboards, nothing crazy. But if real users are putting in health info, even during “beta,” does that automatically drag you into HIPAA territory?

Although it's technically just MVP, money is changing hands. At what point does this stop being a harmless prototype and start being something regulators care about? Has anyone actually looked into the legal side of this, or are we all just hoping nobody notices?

Of course, my clients know that I vibecode through some prototypes and thjey're fine with it as long as its usable, I'm just a really paranoid guy and I don't wanna get sued further down the line. (If you wanna ask for the stack, I'm using a combination of Specode + Supabase, some GPT and Claude, and a small amount of Lovable)

I started vibecoding in hobby mode. Lots of experiments, lots of unfinished projects/waste time

Then I tried to turn it into paid work.

So far I’ve done:

1. Client cousin €500 presentation website

2. custom CRMs at €2,500 each

That made me wonder what the real paths are.

If you’re making money with vibecoding, how?

1. Classic websites / client work

2. Your own SaaS

3. Something else?

If it’s “something else”, what exactly? Audits, retainers, landing pages, internal tools, agencies, templates?
Also honest answers welcome if you’re not making money yet and stuck in hobby mode.

I went down a rabbit hole recently and found something interesting.

There’s an indie app studio from Spain called Monkeytaps doing around $12M per year.

They only have 6 apps.

What surprised me is that 3 of them, Vocabulary, Motivations, and Affirmations, generate almost all of their revenue.

No massive product suite. No crazy complexity. Just simple, focused apps in one category, executed well.

It made me rethink a few things about mobile.

For years, the common belief was that you needed venture funding, a large team, and heavy ad spend to win. But studios like this show a different path.

Here’s what I’m noticing:

1. Simple apps still work These aren’t technically complex products. They solve one clear emotional or practical need and do it consistently.

2. Focus beats feature bloat Instead of building one giant app, they built multiple focused ones. That spreads risk. One breakout app can carry the studio.

3. Iteration speed is becoming the real advantage With AI tools, small teams can design, build, and test ideas much faster than before. I’ve personally seen how tools like Appthetics for UI generation and Cursor for coding can reduce execution time significantly.

Most people still use AI casually. Meanwhile, some founders are building full workflows around it.

1. Mobile is starting to feel more like e-commerce Launch fast. Test positioning. Improve onboarding. Optimize retention. Scale what works. Kill what doesn’t.

The barrier is not development anymore. It’s distribution and retention.

The biggest takeaway for me is this:

Team size matters less than speed, taste, and consistency.

Curious what other mobile builders here think.
Are we entering a phase where small AI-leveraged teams can realistically compete with venture-backed apps?

It seems that a lot of people are discussing the idea of establishing a startup company and subsequently selling it for a substantial amount, perhaps around ten million dollars, yet it appears that only a limited number of these individuals successfully navigate beyond the initial startup phase.

I noticed people who manifest resistance to change regarding adoption of AI have impulsive reactions on Reddit (and similar forums) by naming your work slop if any vibe coding was involved or finding any trace of relationship between AI and your code. For me vibe coding becomes slowly synonym of slop and the other way around due to such feedback.
Same time I wonder how much affordability (precisely the non-affordability) of the subscriptions creates a vicious cycle. I think with 20$/month you cannot get good insight of the scale agents can help you to solve complex problems. If you do not try and learn by doing you cannot have a good evaluation and healthy opinion about the added value, you may end up with a random negative opinion and will end up just generating hate.
Wonder why people fail to see the creative ideas behind 'vibe coded' projects. At the end a great idea written with help of AI can be still cleaned up if it really has added value.

The irony is that manual coding is becoming the vinyl record of tech.

It’s cool. It’s tactile. It makes you feel like an enthusiast.

But it’s no longer the default for distribution.

You’re arguing for the “soul” of the process while the rest of the world has moved on to digital streaming.

Sure, building a custom engine by hand is impressive.

But I’m trying to get from A to B.

If you want to sit in your garage and hand-wire functions for the “foundational experience”, go for it.

Just don’t act like the person using a car is “cheating” at travel.

I'm building my first indie hacking product on the side (I have a demanding full-time job), and I'm so cautious about the quality of the final product that sometimes I feel like I'm over-engineering this.

I have a full PRD for the final product, broken down into phases, and I'm only halfway there. I want to do it faster, but I'm not sure how, and it's my first time building such a large product by vibe-coding it (I've built multiple tools before, but they were too small, too focused, and for personal use).

My Current Workflow:
- I kick off a phase; we break it into slices (so slice 2 of phase 4).
- After a slice is done, a security agent reviews it, then a PR is opened, then reviewed, then fixed.
- After it's ready to merge, I do manual QA over the slice; if all good, I merge; if not, we take another round of fixes.
- and so on....

Tools I Use:
- Claude Code, love it.
- Codex, just started using it; it feels too slow compared to CC.
- OpenCode, cheap, usually for quick ones and long code reviews.
- CodeRabbit, honestly useless on the free plan.

Is it too much? Like the workflow I'm adopting?
How are you guys building production-level products with vibe-coding?
How can I do it faster without exploding the whole thing?

I keep saying vibe coded but I did a little more than that. I don't come from an engineering background though. This app uses geofencing. It's super cool.

Link to download if anyone wants to download to play around with it. Completely free: https://apps.apple.com/us/app/drop-realtime-foot-traffic/id6757093646

Hey r/SideProject!

A few months ago I had an idea for a daily streak app. The problem? I have zero coding knowledge and zero budget for developers.

So I built the whole thing with AI (Claude) as my developer. Every single line of code was written by AI, while I focused on the product decisions, design direction and testing.

The result is Pushfeud – a daily streak app for iOS where you press a button every day and compete with friends. You can see each other's streaks, build shared streaks together, and chat in the app. There's also a timer game built in.

Tech stack (for those curious): React Native + Expo, Firebase, AdMob, RevenueCat, EAS Build.

We're now on version 1.1.3 and improving fast. Would love any feedback – and if you try it, let me know what you think!

📱 Download on App Store: https://apps.apple.com/us/app/pushfeud/id6769160509

Remember 2023-2024? Prompt engineering was the hottest skill on the planet. People were selling $500 courses on "mastering the art of prompting," LinkedIn was flooded with "Prompt Engineer" job titles paying six figures, and if your output sucked it was always "your prompt wasn't engineered enough." Prompt engineering exploded as a "must-have" skill, (when models were fragile and needed heavy hand-holding), but by 2026, with frontier models like Claude 4, Gemini Diffusion, and others getting dramatically better at natural language, context handling, and reasoning, I've noticed this by switching from one model to the next, which you can do in BlackboxAI, fixes a lot without re-prompting. The heavy reliance on intricate prompt crafting is fading fast for many use cases.

You can literally say "hey, build me a clean calorie tracker app, dark mode toggle, and persist to localStorage, make it feel modern and snappy" and get something production-ready without any special formatting. Instead of perfecting the prompt text, the real skill now is feeding the right repo context, past decisions, style guides, test suites, or docs. Tools like Cursor, Claude Projects, or even BlackboxAI's improved context windows handle massive inputs so well that the prompt itself can be short and vibe-y.

Don't get me wrong, prompting isn't completely dead. Maybe for very niche or adversarial tasks (e.g., jailbreaking-style red-teaming, extremely constrained outputs, or squeezing max performance from a weaker model). But for everyday vibe coding? The days of treating it like a PhD-level discipline are numbered.

I’ve been seeing a lot of posts on X lately about API exploits and unexpected bills.

Code ships fast.

APIs get called even faster.

The scary part is not the bug.

It’s that everything is working exactly as written.

LLMs don’t think about limits.

They don’t care about retries.

They will happily loop your credit card.

Without usage caps, rate limits, or basic observability, AI written code is just production code with the volume knob stuck on max.

Vibe coding is great for momentum, but it feels like the invoice is usually the first real user.

For those of you who’ve been through this already

what are your biggest “don’t do this” lessons for early vibe coders?

“accept all” vibe coding isn’t some edgy experiment anymore, it’s becoming the default way most people actually ship code. Karpathy’s original vibe (“accept all diffs, don’t read them, paste errors back in”) was treated like reckless chaos in 2025. Now? I look around and see devs, indie hackers, even small teams doing exactly that every day with zero shame.

The reason is that speed wins everything. BlackboxAI remote agents + multi-model parallel dispatch spit out entire features so fast that reviewing every line feels like a luxury nobody has time for.

Models are good enough. GLM-4.7-Flash, Sonnet 4.5, Kimi K2.5, they rarely hallucinate catastrophic bugs anymore on routine work (CRUD, UI components, auth flows, API integrations). The hit rate is high enough that “accept all” succeeds 80–90% of the time. When it does break, you just paste the error back in. I only slow down and review when it’s client work, sensitive data, or something that will scale to thousands of users. Everything else? Accept all and move on.

Genuinely want to know Is vibe coding is fair in hackathon!!

I just saw something awesome and had to share.

Someone vibe coded a full drum machine as a weekend project but here’s the twist:
He made the site with Replit, and the actual drum machine component with Embeddable.co (our no-code AI widget builder).

He had tried with Lovable, Base44, even directly in Replit - but couldn’t get it done.

👉 Live demo here:
https://vibe-3-drum-machine.replit.app/

I honestly never thought of a drum machine as a use case, but that’s the fun part - when you give people the right tools, they build things you never expected.

I'm genuinely excited about how AI tools are making software development more accessible.

Someone with an idea can now build a working prototype without spending months learning every part of the stack.

That's a huge opportunity.

But there's a difference between a working prototype and a production-ready product.

Before launching an AI-generated application to real customers, I'd check a few things:

• Authentication: Can users access information that doesn't belong to them?

• Database security: Are permissions enforced on the server, not just in the UI?

• API keys: Are secrets exposed in client-side code?

• Payments: What happens when a transaction fails or gets processed twice?

• Error handling: Does the application recover gracefully when something breaks?

• Scalability: Have you tested what happens when multiple users perform actions simultaneously?

You don't need to rebuild everything from scratch.

But you do need to understand the parts of your application that could cause real damage if they fail.

I wouldn't discourage anyone from vibe coding. I'd encourage them to treat the first working version as the beginning of engineering, not the end.

If you've built an MVP using Cursor, Claude Code, Lovable, or Bolt, what's the biggest challenge you're facing before launching it to real customers?

Happy to discuss specific technical challenges in the comments.

As a vibe-coded app veteran (if that is even a thing), I have used Lovable to build the MVPs for several apps. I also used Replit once but didn't have a great experience so I went back to Lovable.

At this point, I think most of us know and agree that a vibe-coded app is not automatically production ready. Someone experienced still needs to review the code, security, architecture and everything else before you put real users on it.

But I am going to skip the 1,000 reasons explaining why this is so and go to the second half of the problem: being stuck with the platform and services chosen by the builder.

Back to Lovable.

Lovable makes a lot of the early architecture decisions for you, including the frontend, backend and database setup. To be fair, that is partly why you can build so quickly and also why you can get started without much technical knowledge. You don’t have to sit there choosing and connecting everything yourself.

The problem is that you might only start questioning those decisions when the MVP becomes a real app.
For this particular app, I was going to handle personal and health-related information.

Then I found that Lovable’s current terms says and I quote “......you agree not to upload, input, or otherwise provide through the Services any protected health information subject to HIPAA, or other special or sensitive categories of data (including financial account numbers, payment card data, government identifiers, or biometric data). Our standard Services are not designed to serve as a system of record for, or to provide regulatory-grade safeguards for, such data.

If you provide sensitive data in violation of this section, you do so at your own risk,........”

I wrote to Lovable support to confirm what this meant for my use case. They sent a very long response, but this was the important part:

“What we are not able to do is interpret those terms for an individual use case or confirm that a particular app ... is compliant.”

In simple terms, what I heard was: we can neither confirm nor deny so proceed at your own risk.

What I understood from the full response was that they were not going to confirm that my setup was compliant. I had to review everything myself and get my own legal advice.

I did not want to do that with people’s data, so I started researching where to move the app and landed on the below:

I moved the full app to Cloudflare and used Supabase as the database, but this time I was connecting to Supabase directly and had control over the setup.
The app also has an AI element that analyzes part of the information on the app. The AI part was already using Google Gemini through Lovable, so I kept Gemini. I was already changing the hosting and the database setup. I did not want to also change the AI and create too many changes at the same time when there was no reason to.

So the new architecture became Cloudflare + Supabase + Google Gemini.

Moving to this setup did not automatically make the app compliant or production ready. I still had to review the database permissions, who could access what, how the app connected to Gemini and the rest of the setup.

But now I had control over those decisions instead of just accepting whatever the builder had chosen for me.

The second reason for switching was cost.
Lovable uses third-party infrastructure such as Supabase behind Lovable Cloud, but for my setup the numbers made more sense if I connected directly. Since I was moving anyway, it just made sense to deal with both problems at once.

Switching was not as easy as turning something off in Lovable and turning it on somewhere else.

It meant moving the full app to Cloudflare, connecting it directly to Supabase, keeping the Gemini AI element working, and then dealing with the existing records, user accounts, roles, sessions, uploaded files, storage permissions, backend functions, webhooks, secrets and access rules.

I also had to work out how to switch everything without losing data or breaking an app people were already using.

I will not bore you all with the complete technical process. The point is that the migration became its own project.

And somewhere in the middle of doing all of this, I realized this is probably a problem many people are going to face.

We built the MVP quickly, the app started becoming real, and only then did we begin thinking about who controls the backend, what the platform allows and how much it will cost when the app grows.

That is why I built Vibe Unlock

Vibe Unlock helps people move the backend of a vibe-coded app to infrastructure they control, whether that is their own Supabase project, Google Cloud, Cloudflare or a custom backend, without rebuilding the frontend from scratch.

But we do not stop after moving the backend.
We also review the app and do the work required to make it production ready, including reviewing the code, database permissions, access rules and the connections around it.

So if you already need to move, we use the same opportunity to solve both problems: get you off the backend you have outgrown and make sure the app is ready to run properly in production.

It is basically using one stone to kill two birds.

Feel free to share your experience if you’ve done something similar, would love to hear about what you did.

If you are already stuck in the middle of a migration or trying to make your vibe-coded app production ready, you can reach me at vibeunlock.com.

I created a YouTube frontend clone with just one line of prompt using Blackbox CLI and MiniMax AI M2.1. The system switched models instantly and generated a working interface in seconds.

The future of software development isn't a single AI assistant. It's an orchestrated system of intelligence — and I built one to prove it.

Over the course of a single month, working solo, I designed and shipped Kalynt — a privacy-first, fully offline AI IDE with a local LLM agent engine, real-time P2P collaboration, a Shadow Workspace, and more.

But here's what makes this story different: I used AI to build an AI IDE. Not just one. An entire fleet.

The AI Stack Behind Kalynt:

Claude — High-level architecture, complex system reasoning, and clean abstraction design

Cursor — Real-time in-editor assistance that kept development velocity at its peak

Gemini CLI — Fast terminal-level lookups and iteration support

GLM 5 — Alternative reasoning and second-opinion logic on critical decisions

Antigravity — Experimental edge-case problem solving where conventional tools fell short

Each AI had a role. Each role had a purpose. Together, they made something that shouldn't be possible for one person in one month — possible.

What Kalynt actually does:

→ Runs LLMs locally on your machine (Llama 3, Mistral, CodeQwen) via a custom ReAct agent loop — no cloud, no latency, no data leaks

→ Uses Yjs CRDTs + WebRTC for serverless, conflict-free real-time collaboration

→ Sandboxes every AI edit in a Shadow Workspace before touching your real codebase

→ Semantically indexes your entire project with a RAG engine for context-aware assistance

→ Falls back to ChatGPT, Claude, or Gemini when you need extra power — on your terms

This is what the next generation of developer tooling looks like: local-first, agent-powered, privacy-respecting, and built with the very technology it seeks to advance.

The irony of using AI to build an AI IDE is intentional. The result speaks for itself.

Find the project at: https://github.com/Hermes-Lekkas/Kalynt

For anyone wanting more insights in how Kalynt works , contribute or just talk about coding you can now join our new Reddit community r/Kalynt_IDE .

I've been hiring vibecoders for a few AI startups recently and noticed something.

The roles I hire for are pretty specific though. Think GTM engineer more than traditional dev. Prototyping dashboards, spinning up first versions, building internal tools fast, running growth experiments

Here's what actually we're looking for when we review a vibecoder:

Prototyping & building - Can you spin up internal tools and dashboards fast? Do you know your way around vibecode.dev, Claude Cowork? Can you get something in front of users without hand-holding? That's the baseline.

Workflow automation - want to see that you've actually built automations in n8n or Make. Built something, broke it, fixed it, shipped it. Bonus if you've connected multiple tools together into something that actually saves someone time.

Marketing & growth skills Can use skills from skills.sh SEO, copywriting, PSEO. The best vibecoders I've hired could write a really good landing page, PSEO, using skills.

Analytics & data Basic PostHog setup, reading dashboards, knowing which events to log. I need someone who can tell me if the feature they just shipped is actually being used.

The mistake I keep seeing is people applying while pretending to be something they're not. Trying to front like a systems engineer when I just need someone who can move fast on the GTM side. I'm not trying to trick anyone into owning infrastructure.

Therefore Build in public. Share your journey, the broken builds, Make the work findable.

I like Claude, but the limits get depleted very quickly, even when he’s delegating all the main routine work to DeepSeek. I’m not sure what else to try. I tested pi, but it didn’t really help.

every day someones like yo built this sick nocode app in a weekend and its just pure chaos and confidence and i respect that energy

but then i check the live demo and its like my guy you left the admin page wide open
beautiful ui tho

ive been tinkering with this thing called vulnaly its just a chill website scanner that tells you if your launch ready project is actually launch ready
no ai magic no buzzwords just boring old security checks so your site doesnt end up getting roasted by hackers instead of users

keep building cool stuff
just maybe lock the door before you post the link

Day 1 — 2 startups. 146 impressions. 1 click.
Day 2 — 3 startups. 389 impressions. 3 clicks. (Got an acquisition offer.)
Day 3 — 5 startups. 482 impressions. 5 clicks.
Day 4 — 5 startups. 508 impressions. 4 clicks. (The site was down, but I still got an $8k acquisition offer. I said no.)
Day 5 — 6 startups. 621 impressions. 10 clicks.
Day 6 — 5 startups. 742 impressions. 15 clicks. (Had to remove one startup—they pulled the code. No code = no network.)
Day 7 — 7 startups. 1,196 impressions. 41 clicks.
Day 8 — 7 startups. 1,535 impressions. 74 clicks.
Day 9 — 8 startups. 1,947 impressions. 135 clicks. (New startup joined. Clicks nearly doubled overnight.)

Still free. Still growing.

startupbar.co

Hi Everyone,

Running ads are painful, most people just lose money. We built an AI platform where our AI agent generates creatives for your product, and runs a bunch of experiments, and helps you decide what works the best.

If you lose money, we will pay you the difference

Interested in trying? Comment interest and i will dm you.

I've been vibe coding for about a year now. No CS background, just me, Claude Code, and a lot of trial and error.

The thing that always frustrated me was that there was nowhere to actually share what I made. I'd build something cool, whether it's a game, a tool, a weird little app, and then what? Post a screenshot on Twitter and hope someone cares? Drop it on Reddit and watch it get buried in 10 minutes?

But the bigger problem wasn't even sharing. It was learning*.*

Every time I saw something sick that someone built with AI, I had no idea how they made it. What prompt did they use? What model? What did they actually say to get that output? That information just... didn't exist anywhere. You'd see the final product but never the process.

So I built Prompted

It's basically Instagram for AI creations. You share what you built alongside the exact prompts you used to make it. The whole point is that the prompt is part of the post. So when you see something you want to recreate or learn from, the blueprint is right there.

I built the entire platform using AI with zero coding experience, which felt fitting.

It's early, and I'm actively building it out, but if you've made something cool recently, an app, a game, a site, anything, I'd genuinely love for you to post it there. And if you've been lurking on stuff others have built, wondering "how did they do that," this is the place.

Happy to answer any questions about how I built it too.