Buildside

Public archive

Founder updates

Original, substantive public posts from SaaS founders. Personalized feeds and private activity are never included.

Lesson by Uriel Bitton

Day #8 building apptruth in public 🚀 I realized Apptruth…

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.

Read the full public discussion

Progress by Uriel Bitton

Day 7 building AppTruth in public A cool use case I…

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.

Read the full public discussion

Progress by Uriel Bitton

Day #4 of building AppTruth in public

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?

Read the full public discussion

Progress by Uriel Bitton

Just launched on ProductHunt 🚀

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

Read the full public discussion