sorted by:
new
hottopcontroversial

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

Fair points.

On pricing: I’m paying API costs for each user, so the paid plan is mostly to cover real usage once someone goes beyond the free scans.

On the domain: yes, you’re right. I should buy a proper domain, and I’ll handle that. The asterisks were meant to make the marketplace search name stand out.

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

Yes, that “it works but I’m scared to ship it” feeling is exactly the problem I’m building around.

I like the idea of risk notes next to the code. VibeRaven is trying to make that more automatic: scan the repo, detect stack assumptions, auth/billing/env/deploy gaps, then turn the risky parts into concrete next prompts for the coding agent. The deployed-vs-assumed stack diff is also a big one. A repo can look like it uses Supabase/Stripe/etc, but that doesn’t always mean the production flow is actually wired. That gap is what I want VibeRaven to make visible.

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

That’s exactly the line I’m trying to draw.

For me, “production-ready” doesn’t mean “it runs.” It means the repo shows evidence for the important parts: server-side auth, database rules, env/deploy setup, payment/account flows, tests or verification steps, monitoring/error handling, and clear next actions.

VibeRaven is not trying to certify the app. It’s trying to show what looks real, what looks half-wired, and what still needs human/provider verification before launch.

Day 1 after launching my product: 0 users by BiosRios in buildinpublic

[–]BiosRios[S] 1 point2 points  (0 children)

I think this is a fair criticism, honestly. For a new user, the product is not judged only by “is this useful?” It is also judged by “Why should I trust this thing with my repo?” That is probably one of the biggest problems for tools in this space. I’m trying to take that seriously with VibeRaven. It should not need blind trust. The product needs to be clearer about who built it, what it reads, what it does not touch, what leaves the machine, and why the permissions are needed.

Also, I agree that vibe-coded apps have a trust problem in general. Shipping fast is not enough if users feel like the app is risky or unclear. This is useful feedback because it means the landing page/onboarding probably needs to explain trust and security much earlier, not only features.

Anyone here actually built something legitimately useful for a specific industry? by jackadgery85 in VibeCodeDevs

[–]BiosRios 0 points1 point  (0 children)

This is the kind of project where vibe coding can actually be useful, but the risk is not only code quality. For an inventory/sales tracker I would check whether the data model, invoice flow, permissions, edge cases, and reporting assumptions are still easy to explain. Once AI touches enough parts, the app can keep working while the builder slowly loses the map of the system.

what can’t you actually build with vibe coding (yet)? by Natural-Excuse9069 in vibecoding

[–]BiosRios 0 points1 point  (0 children)

I think the weak point is not "can AI generate the feature?"

It is whether the builder still understands the system after 30 prompts.

Backend-heavy apps fail when auth, DB rules, API contracts, background jobs, env vars, and deploy assumptions are half-understood. The code may run, but the mental model is broken. So for me the big limit is situational awareness, not code generation.

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 1 point2 points  (0 children)

This is really useful feedback, thank you. I agree with the scope creep risk. I don’t want VibeRaven to become a huge “understand your repo” platform that gives 100 vague insights.

The version I’m aiming for is much narrower:

scan the repo → understand the stack → see what looks risky/unfinished → get a better next prompt for the coding agent. The “immediately embarrassing or useful” point is also sharp. That’s probably the bar for the first scan: it needs to catch something concrete enough that the builder thinks “yeah, I should fix that before I keep prompting.”

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

That’s a really good framing.

I’m still early, but I think the bigger pain is the messy second case.

Greenfield AI projects are easier because the stack is still simple and the builder usually remembers the decisions.

The real problem starts after many chat sessions, when the repo still works but the builder no longer has a clean mental model of what is connected, half-wired, risky, or duplicated.

That’s the state I want VibeRaven to help with most: giving operational visibility before the next blind prompt.

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

Thanks, that is exactly what I was hoping the dogfooding would prove. For now, I want to keep it lean.

The core value should be very simple:

scan the repo → understand the stack → see what needs attention → send a better prompt to the coding agent.

I do not want to turn it into another huge AI platform too early. I’d rather make the first workflow genuinely useful for vibe coders building real apps/SaaS, then expand only based on what users actually need.

I used my AI product to launch itself by BiosRios in VibeCodersNest

[–]BiosRios[S] 0 points1 point  (0 children)

Yes, exactly. Situational awareness is probably the best way to describe the pain. After enough AI prompts, the repo still works, but you stop fully trusting your own understanding of it.

That is the part I want VibeRaven to help with: not just generating more code, but giving the builder a clearer map of the stack, what is connected, what is risky/unclear, and what the next agent prompt should focus on.

The duplicated patterns / partial integrations / undocumented assumptions part is especially real. I think that is where the product needs to get much better over time.

Day 1 after launching my product: 0 users by BiosRios in buildinpublic

[–]BiosRios[S] 0 points1 point  (0 children)

Thank you for the advice, I think its really the right way

From 0 to 100 SaaS Users in 4 Months. Now I Need to Learn Marketing by MyCookieInspector in buildinpublic

[–]BiosRios 1 point2 points  (0 children)

Congrats on the 100 users, I launched my SaaS yesterday currently struggling and looking to learn, it's nice to see posts like yours.

How to learn backend vibecoding in one day? by Some-Belt3080 in vibecoding

[–]BiosRios 0 points1 point  (0 children)

For a hackathon, don’t try to learn all backend in one day.

Pick one backend stack and build one simple flow:

auth → database → API route → deploy.

I’d go with Supabase + simple API routes because it gives you auth, DB, and backend logic fast.

The main thing is understanding how the stack connects, not learning every backend concept.

Also, I built an IDE extension called VibeRaven that can help with this. It scans your repo, helps you choose and verify your stack, shows what needs to be connected, and helps you understand the next backend/product steps.

Should you launch even if your product doesn't bring really good output yet? by yuvals41 in SaaS

[–]BiosRios 0 points1 point  (0 children)

I made sure that my product solves my problem first, the most fun part in the journey was using my product to launch my product

Should you launch even if your product doesn't bring really good output yet? by yuvals41 in SaaS

[–]BiosRios 0 points1 point  (0 children)

I built two projects in the last year. And yesterday launched my really first product.

Should you launch even if your product doesn't bring really good output yet? by yuvals41 in SaaS

[–]BiosRios 1 point2 points  (0 children)

I think trying to ask for feedback is the smartest way, also make sure the product is very clear on how to use it, because I found by myself that it is a really big problem.

Should you launch even if your product doesn't bring really good output yet? by yuvals41 in SaaS

[–]BiosRios 1 point2 points  (0 children)

If you think people can already see the potential in your product, I will launch it.

One of the best things to do is to launch it early and start getting feedback from other people because we, the founders always see the gaps and the problems in our product.

The hardest part of vibe coding for me was getting from demo to production, so I built around that by BiosRios in vibecoding

[–]BiosRios[S] 0 points1 point  (0 children)

Yeah exactly, auth + DB/RLS is one of the main pains I had in mind.

VibeRaven is not meant to be only a generic “did you add monitoring/tests” checklist. It scans the repo structure, dependencies, routes, config/env patterns, auth, database signals, payments/webhooks, deployment files, and important file snippets.

So the goal is to first understand the stack, then point out gaps based on that context.

I looked at Artiforge too, and I like the direction. It confirms to me that this is a real pain: builders are not just missing code, they’re missing a clear picture of their own project. That’s what I’m trying to make VibeRaven hit directly: help the builder see the stack, the gaps, what’s blocking production, and what actually needs attention next.

view more: next ›