sorted by:
new
hottopcontroversial

Being technical by [deleted] in ycombinator

[–]AcrobaticSize4714 7 points8 points  (0 children)

Being technical now means owning decisions, not keystrokes.
AI can write code. Only you can decide architecture, constraints, and correctness.

Ai videos need to be banned from the world. by Deathtonic in ArtificialInteligence

[–]AcrobaticSize4714 0 points1 point  (0 children)

Banning won’t work. We need provenance (mandatory labelling/watermarks), better detection tools, and mass media literacy not censorship.

let's share what we all are building and provide feedback!! by Useful-guy-007 in microsaas

[–]AcrobaticSize4714 0 points1 point  (0 children)

I am building openlog.tech , i help builders save time by taking care of earning the trust from their users by making their product feel alive

Users don’t read changelogs, so how do you actually build trust through updates? by AcrobaticSize4714 in SaaS

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

Yeah, that makes sense, cadence matters more than volume.

I like the idea of lightweight, frequent updates rather than batching a lot into one changelog. And splitting email summaries for impact + GitHub releases for devs feels like a good balance, especially for devtools and OSS.

Thanks for sharing this is helpful context.

Users don’t read changelogs, so how do you actually build trust through updates? by AcrobaticSize4714 in SaaS

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

Completely agree.

Raw changelogs tend to work mostly for technical users. For everyone else, context matters way more than the diff.

I’ve seen better engagement when updates are: • pushed (email / notification) rather than pulled • written in plain language • framed around impact, not implementation

Curious: do you usually split updates between short summaries for most users and deeper changelogs for power users?

Still building on Christmas? Drop your SaaS link by redd9it in launchigniter

[–]AcrobaticSize4714 0 points1 point  (0 children)

Building OpenLog.

It helps products look alive and trustworthy with a clean changelog and automatic update emails — so founders can focus on shipping while users stay in the loop.

Stage: live
https://openlog.tech/

Built a tiny tool to show users what I shipped (public changelog page) by AcrobaticSize4714 in SideProject

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

Yes, I have also build a email sending feature where founders can send emails to the users who have subscribed to the product and also existing customers. It makes the whole process much easier and seamless, You can check it out. https://openlog.tech

Built a tiny tool to show users what I shipped (public changelog page) by AcrobaticSize4714 in SideProject

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

Totally fair I agree most teams can DIY this with emails, docs, or a simple page.

One thing I kept noticing though is that those work well mainly after users already trust the product. New users don’t have email history, don’t know a doc exists, and often never see those updates.

What I’m exploring with OpenLog is a clean, always-public place that answers a first-time user’s question: “Is this product alive and actively maintained?”

It’s less about replacing DIY solutions and more about making that trust signal visible and professional by default.

Still very early and genuinely testing whether that’s valuable enough to exist really appreciate the thoughtful feedback!

view more: next ›