HNHacker News
TopNewBestAskShowJobs

rubenhellman

2 karma · joined December 15, 2025

submissionscomments
rubenhellman··on Vibecodeprompts treats prompts like infrastructure
I have been playing with Vibecodeprompts for a bit and what stood out to me is not the prompts themselves, but the framing.

Most “prompt libraries” assume the problem is wording. As if better adjectives or clever roleplay magically produce reliable systems. That has never matched my experience. The real failure mode is drift, inconsistency, and lack of shared structure once things scale beyond a single chat window.

Vibecodeprompts seems to implicitly accept that prompting is closer to infra than copywriting.

The prompts are opinionated. They encode assumptions about roles, constraints, iteration loops, and failure handling. You can disagree with those assumptions, but at least they are explicit. That alone is refreshing in a space where most tools pretend neutrality while smuggling in defaults.

What I found useful was not copying prompts verbatim, but studying how they are composed. You can see patterns emerge. Clear system boundaries. Explicit reasoning budgets. Separation between intent, process, and output. Guardrails that are boring but effective.

In other words, this is less “here is a magic prompt” and more “here is a way to think about working with models as unreliable collaborators”.

That also explains why this probably will not appeal to everyone. If you want instant magic, this is not it. You still have to think. You still have to adapt things to your domain. But if you are building anything persistent, reusable, or shared with other people, that effort feels unavoidable anyway.

Curious how others here think about this. Do you treat prompts as disposable glue, or as something closer to code that deserves structure, review, and iteration over time?

rubenhellman··on A lightweight SaaS to reduce early stage app friction
I recently shipped a small SaaS, mostly during school breaks. This is my first project that I have taken from idea to deployment, onboarding, and real users. The product targets early-stage developers and focuses on reducing initial setup and preparation when building new apps. It abstracts away some of the repetitive early decisions and boilerplate that tend to slow down first-time builders, especially around project structure, configuration, and “what should exist on day one”.

I have a small number of active users, but churn is relatively high, which suggests either:

the problem is not painful enough

the abstraction leaks too early

the UX or onboarding fails to communicate value

or the tool solves a problem that disappears after the first session

I would really appreciate technical feedback on:

whether the abstraction layer makes sense

if the mental model aligns with how you bootstrap projects

where the product feels opinionated vs restrictive

what would make this something you would actually keep installed

Thanks for reading. Direct, critical feedback is very welcome.