Public archive
Original, substantive public posts from SaaS founders. Personalized feeds and private activity are never included.
Lesson by Uriel Bitton
It’s an app that lets people ship real startups. Vibe coding gives you the power to build. But generating an app and confidently shipping it are two very different things. Apptruth succeeded in closing that gap. You describe what the app should do. It analyzes what was actually built, finds mismatches, incomplete flows and launch risks, then shows you what to fix.
Progress by Uriel Bitton
create Github PRs. If you use a npm library on github and it has any type of issue, scan the repo on Apptruth. Apptruth will find the issue and explain exactly: - why it happened - how it happened - where it happened It will then automatically give you the AI prompt to fix it. You can then clone the repo and use the prompt to fix it immediately or submit a PR with the suggested fix.
Ask by Uriel Bitton
Is it better to use “percentage of savings” pricing Or A traditional monthly pricing plan and aim for teams that have much larger spend to justify the static pricing? Let me know in the comments 👇
Experiment by Uriel Bitton
You can now scan any public github repo and see any existing issues or unintented behaviour. This is super useful: you can quickly tell maintainers about an issue with the full what, where, why of the issue for context event with the AI fix it prompt. Try it out here: https://www.apptruth.io
Progress by Uriel Bitton
One of the most sensitive moments in AppTruth isn’t the scan. It’s asking someone to connect their repository. A codebase contains the product you’ve spent weeks or months building. Even when a developer tool promises to help, granting access is always the most action that requires the most trust from the app. That creates a product-design question I’ve been thinking about: What is the minimum access AppTruth actually needs? The answer should always be read-only GitHub repo access. AppTruth needs to understand how an app’s features work, but it doesn’t need permission to push changes into the repository. The results can provide context and AI-ready fix prompts while leaving the decision (and the actual edit) with the users. The tradeoff here is automatically applying a fix might remove a step, but it would also require a much larger level of trust. For a product designed to uncover behavior you didn’t expect, asking for more control than necessary would feel wrong. The broader lesson I’m taking from this is that permissions are part of the user experience. Every permission request should have a clear answer to 3 questions: 1. Why is this needed? 2. What can the product do with it? 3. Could the same value be delivered with less access? What information would you need before feeling comfortable connecting a private repository to a developer tool?
Progress by Uriel Bitton
Day 1: this new app is gonna be fire Day 2: this app is like every other app Day 3: this app is gonna be fire Day 4: it's a bad idea, it can be copied so easily Day 3: this app is gonna be fire Day 5: i need to pivot etc on a loop 🔁
Progress by Uriel Bitton
Dynasight is live today! I would really appreciate all the upvotes I can get 🙏 💡 How it works: 1. Connect your AWS account (100% read-only, no data read only metadata). 2. Dynasight scans your table and detects cost waste, and performance issues. 3. You get exact IaC remediations for every issue found https://www.producthunt.com/products/dynasight/launches/dynasight
Launch by Uriel Bitton
Buildside is a community that encourages SaaS founders to build in public and grow their startups with like-minded people. Share your journey with us. Join us now at buildside.app!