Connect with the Product Hunt community

The engineers who built the most impressive things I've seen never practiced Leetcode.

They learned by shipping.

They debugged at midnight. They read someone else's broken code and fixed it. They reverse-engineered systems nobody documented. They optimized something 40% faster because it was slow and that bothered them.

None of that shows up in a binary search question.

First post here. I've been browsing Product Hunt for a while without an account and finally made one.

I have a problem I suspect some of you share. I keep finding tools, signing up, and then never really using them. Not because they're bad, but because trying something new feels like progress, and then the actual using part never happens. My bookmarks and saved posts are full of things I was definitely going to start using. I opened maybe three of them again.

Meanwhile the tools I actually rely on are a short list I barely think about. Everything else is just sitting there, and I keep adding to it.

I know the obvious answer is to stop browsing and just use what I have, but that's easier said than done when the next interesting thing is one scroll away.

One small UX decision I run into in product design is whether a product should remember what the user selected last time.

Filters, view modes, selected projects, table settings. Remembering these choices can save users from repeating the same setup every time they come back.

But it can also create confusion.

A user returns days later, sees a different result than expected, and doesn t realize an old setting is still being applied.

I edit and comp for film and music videos, and the thing that never got solved for me by any NLE is versioning across a revision chain. A shot goes out, a client says warmer, and pull the edit half a second earlier, someone matches that on a call, exports, and three revisions later nobody can say for certain which output the current cut is actually built on, or whether an older render got reused by accident because the filename still said v3_final.

Most teams I have worked with end up with some combination of folder naming conventions and a shared spreadsheet, which works until it does not. Curious what has actually worked for people outside of ad hoc conventions: do you tag renders with the decision that produced them, keep a structured changelog per shot, or is this just an accepted cost of doing revision-heavy creative work? Especially interested if anyone has automated part of this instead of doing it by hand.

TypeSafe launched Jev last week. It is a System One model meant for typed decisions inside software (classify, route, score, extract, branch), not chat.

I am not on the team. I am trying to figure out if this actually changes how products get built, or if it is just another structured output wrapper with better marketing.

I used to rely on algorithmic feeds like X or LinkedIn to keep up with engineering and design blogs.

Lately though, those platforms feel more filled with self-promotion and hot takes than actual long form articles.

I m thinking about setting up a quiet space where I can just subscribe to personal blogs and technical updates directly without an algorithm sorting my feed.

Every time I check the daily feed and find an interesting product I look at the discussion section and notice I m way late to the party.

The main conversation seems to happen super early and y the time I log on, everyone has already moved on.

Is there a specific time zone or daily routine you guys stick to so you don't miss the initial launch activity?

Curious how you built your daily routine on here once you stopped just casually browsing.

Hi! How do you approach creating a mockups from running Svelte and JS apps? Often I need to quickly visualize how adding a new UI element would look like and get approval for it. Generating HTMLs from scratch for this is error-prone and I was wondering if you might have other proven methods?

I have been trying to find some verifiable data on how many vibe-coded products actually scale and make meaningful revenue. Surprisingly, there does not seem to be much public data on this.
Lovable says millions of projects have been created on its platform, and I know there are some impressive success stories too. But what I can't find is clear data on how many of these projects become commercial products and reach even something like $5K MRR.
That makes me wonder how founders are actually making this decision today. How do you get over the anxiety of accidentally launching something that has a deep technical flaw that, as a non-technical founder, you simply do not have the knowledge to catch?
If you had some capital to invest, a clear business plan and intended to build a real business around the product, would you still prefer to work with professional developers, or would you build and launch the first version yourself using Lovable, Bolt, or Replit and save your capital?
Another thing is that most professional developers themselves now say that they build with AI assistance. But I have a feeling that is still very different from me building the product myself with AI as a non-technical person.
I am especially interested in hearing from non-technical founders who have actually made this choice. What route did you take, and why?

Every "client management" tool I've tried is either built for agencies with a team, or it's just a CRM with freelancer branding slapped on. I've ended up cobbling together Notion + a shared folder + way too many follow-up emails.

Curious what's actually working for people here a real system, or still duct tape? And if duct tape, what's the piece that breaks first (intake forms, invoicing, scope creep, keeping track of who owes what)?

I remember setting up this massive notion workspace with heaps of databases, tags, and weekly trackers.

It looked awesome at first but after a week or two updating the whole thing took more time than doing actual tasks. Eventually I just gave up and went back to writing things down on a quick sticky note.

Curious if anyone else overbuilt their todo system and ended up throwing it away?

Every time we try to write a case study, the biggest bottleneck is actually interviewing the internal team.

Engineers are busy fixing bugs, PMs are on to the next launch, and nobody remembers the exact metrics from months ago.

It feels like 80% of the effort goes into back-and-forth calls just trying to rebuild what actually happened before writing a single word.

How does your team capture project details early so you don't have to chase people down later?

Most free tiers strip out enough features to drive you to paying for a product. We took the opposite approach: All the features work for free for ever, but for only one user. Then you pay for a second user who wants to join the workspace.

The trade-off is genuine. We have a large solo user base and most of them will never pay. Our free-to-paid ratio is less than 2% which would scare an investor.

Mine ranked nowhere on launch day. Barely any upvotes, quiet comments, felt like a non-event.

A month later: 1600+ users, 500+ signups, 250+ people who came back without being asked to.
Zero ad spend, none of it came from PH.

My honest take, this platform is mostly tech people, developers, builders, saas folks.
If your product's for that audience, a strong launch here can genuinely be everything. If it's not, like mine, a quiet launch here doesn't mean the product's bad, it just means this wasn't the room for it.

If your launch flopped and you're sitting there thinking the product's the problem, it might not be. Sometimes it's just not the right audience for that specific day.

I won't name the product/app, but their AI Chatbot responded in Python and then created another simulation script in Python. Is this normal? Should I contact the company or share the findings publicly?

Ran a quick test campaign on android and get cheap installs but almost nobody actually started using the app after signing up.

Hard to tell if the ad just brought in curious clickers who don't really care about tracking workouts, or if my first screen has way too many buttons and steps.

For anyone who faced this early on, how do you figure out which side is actually broken first?

It s crazy how easily a new app can blow you away in the first five minutes. The landing page looks polished the demo video is clean and onboarding is smooth yet a week later, you forget it even exists.

AI makes building a great looking prototype super fast but it doesn't fix long term utility. We end up spending way too much time hype-building for day one instead of making something people open daily.

How do you stay focused on long-term retention when shipping a fancy demo is so tempting?

I always thought having a cheap entry level plan was necessary to catch hesitant buyers. But after struggling with flat sales despite copy rewrites removing that budget option was what finally worked for us.

Instead of boosting signups the cheapest tier was just acting as a safety net that kept users from choosing the product version that provided real value.

Curious if other founders have experienced this did removing your cheapest option helps or hurt your overall revenue?

Posting updates every single day sounds great until it starts eating into your actual building time.

Spending an hour daily tracking follower counts or numbers often takes focus away from fixing bugs or making the product better.

Plus taking a step back from constant posting doesn't seem to hurt credibility or lose users like many fear.

Have you noticed any real sales coming directly from building in public or is it mostly just noise?

A two minute check for anyone running a long-lived app server: PHP under RoadRunner or Swoole, Node, anything where one process serves request after request instead of starting fresh each time.

List the values your templates read that middleware sets per request: the signed-in flag, the avatar, the CSRF token, the analytics user id. Then ask what each of them holds on a request where that middleware did not run.

In a process-per-request world the answer is nothing. In a long-lived worker it is whatever the previous request left behind. In my framework those values sit in one shared object for the life of the worker, a plain array that middleware writes into. The next request that skips the middleware reads the values the last one left.

On most of my pages that never shows, because every request runs every middleware and overwrites everything. It matters on the group I built to be cacheable. My public pages run no session and no CSRF on purpose, so a shared cache is allowed to store them, and that means they skip exactly the middleware that would have overwritten the leftovers. A template there that printed the CSRF token would have printed the token of the previous visitor, into a cache entry served to everyone. A check for cookies on cacheable responses does not catch it, because the value never travels as a cookie.

I've been collecting exchange announcements for a while and I keep running into the same wall: almost everyone expects you to poll an HTML page or a support-article endpoint.

Two exceptions I've found so far. Binance and Gate.io both let you subscribe to announcements over their own WebSocket streams, so there is no polling interval to sit through and no cache layer in between. Everything else I watch gets polled at high frequency.

I was thinking about how automation can sometimes hide bad operational logic. If an agent continuously fills in missing records behind the scenes everything looks smooth on the dashboard but you're actually normalizing a faulty process.

It feels like AI shouldn't just run fixes in silence it needs to throw a red flag when it has to patch the exact same problem hundreds of times.

For team leads using ops agents how do you keep tabs on what your bots are patching vs what actually needs a permanent engineer fix?

When an ai bot automatically patches an error every single morning like fixing missing order data it seems like a huge win. but the core issue never gets solved at the root cause.

A human worker would get annoyed and report the bug after a few days, while an agent just quietly fixes it thousands of times without anyone noticing the system is actually broken upstream.

Here s a failure mode I don t see discussed much.

Imagine an operations agent notices that every morning, 30 orders arrive with incomplete shipping information.

So it: