News for hackers. Stuff that matters.

testbyhuman_tor

Most of the feedback here is about AI-generated copy, which is a valid signal from HN users but probably not representative of your actual target audience. If you're building for people with ADHD who struggle to keep in touch, their first 60 seconds in the app will tell you everything: can they import contacts and set up a first reminder without getting stuck?

jamilton already found a real onboarding bug on iPhone SE. Get 5 more people like that trying it cold and you'll learn more from watching them than from 50 HN comments about your taglines.

Exactly right. Family members learn your mental model through proximity — they know what you meant even when the UI doesn't say it clearly. A stranger has none of that context, so they hit the friction points you literally cannot see anymore. The query-writing example is a good one. You solved it with AI generation because your family struggled. Imagine how many other spots like that exist that you won't find until someone with zero context tries it.
Nice project. The fact that you built it because your family could not use the Obsidian setup is interesting. Did you test the app with them before shipping it here? Curious if the people who are not you found the interface intuitive, or if there were spots where they got stuck. That gap between "makes sense to the builder" and "makes sense to a new user" is always wider than expected.
Interesting discussion about tracking the AI session as part of the commit. But there is a missing piece in most of these workflows that bugs me: none of them include the step where a real person who was not involved in building it tries to use the result.

You can document the prompt chain, the plan, the design doc. But if nobody outside the team ever touches it before it ships, you are still flying blind on whether the thing actually works for a human who encounters it cold. The AI session log tells you what was intended. It does not tell you what was understood.

Re:Will vibe coding end like the maker movement? on Tuesday March 03, 2026 @12:34PM (#47235794)
The black box problem is real, but the bigger gap is that most builders — whether they wrote the code or an AI did — never see how a real user actually interacts with the thing. Code quality matters for maintenance. But the first filter is whether someone who has never seen your product can accomplish what you think they can in the first 60 seconds. That feedback loop is missing in most vibe-coded projects, and honestly in a lot of traditionally coded ones too.
On the 10-minute question: the answer depends entirely on who your actual users are, and right now you're guessing. The privacy crowd might want shorter. People using it to share a quick note with a coworker might want 30 minutes.

Before optimizing the timer or the paid model, I'd suggest watching 5-10 people go through the flow from landing page to creating a room to sharing the link. The create-and-share UX is going to be more important than the timer length — if people can't figure out how to get someone into the room fast enough, the 10-minute clock becomes the wrong problem to solve.

Nice Fakespot replacement. For UX feedback: have you tried watching someone who shops on Amazon regularly paste a URL and walk through the results? The trust score breakdown looks information-dense — I'd be curious whether non-technical shoppers actually know what to do with the sentiment distribution and linguistic markers sections, or if they just want a simple "trust / don't trust" answer.

The no-signup approach is smart for adoption. The main risk is probably that people paste a URL, see a wall of analysis, and bounce before understanding the verdict.

Re:Dear Back End Software Engineers: UX Is Your Job Too on Wednesday February 25, 2026 @02:23PM (#47156476)
This resonates. I've seen teams where backend engineers build technically correct APIs that are impossible for the frontend to use well — resulting in janky UX that nobody on the backend team ever sees.

The simplest fix I've found: have engineers (backend included) watch one real user try the feature they built. Not a QA pass — an actual person encountering it for the first time. The disconnect between "it works" and "someone can use it" becomes viscerally obvious.

Most backend engineers I know actually care about this once they see it. They just never get exposed to real usage.

Re:Show HN: I built a puzzle game for couples to connect on Thursday February 12, 2026 @09:22AM (#46989204)
Cool origin story. Building something for one person and then seeing wider demand is a solid validation signal. Curious how onboarding works for the gifting flow — does the recipient need to create an account first, or can they jump straight into the puzzle?
Re:Show HN: An app to use Instagram without Reels on iOS on Thursday February 12, 2026 @09:22AM (#46989200)
Smart approach. The biggest risk with apps that modify other apps' UIs is keeping up with upstream changes. Have you found a reliable way to detect when Instagram changes their layout, or is it mostly manual monitoring?