Dev visibility for non-technical founders

[akhnid]

If you're a founder who doesn't code, you probably rely on engineers to tell you what's shipping. That works until investors ask for updates, customers want a changelog, or you just need to know where things stand.

*What it does:*

Connect your repos. Ask questions: - "What shipped last week?" - "What's in progress?" - "Who worked on what?"

Get plain English answers from your commit history.

*Automated reports:*

Schedule weekly or monthly summaries. Delivered to Slack or email. Forward to investors or your board.

*Other features:* - Slack bot for team-wide access - Contributor stats

*Security:*

Webhooks only. We store commit messages, PR titles, timestamps, and authors. We never access source code.

Stack: - Token encryption: Fernet (HMAC-SHA256 + AES-128-CBC) - Webhook verification: HMAC-SHA256 - 2FA support

Verify by checking your repo's webhook settings after connecting.

Free for 1 repo: https://gitmore.io

[jackfranklyn]

The communication gap this solves is real. I've been on both sides - as a dev explaining what "refactoring the auth flow" means to stakeholders, and as a founder trying to translate technical progress into investor updates.

One thing worth noting: commit messages and PR titles are often written for other devs, not for business context. "Fix race condition in checkout" tells you nothing about customer impact. The quality of output from tools like this depends heavily on whether your team writes decent commit messages in the first place.

For small teams where the founder actually understands the product deeply, I've found a weekly 15-minute sync more valuable than automated reports. But I can see this being useful at the scale where you can't have those conversations with everyone.

[akhnid]

Good point on commit message quality. We've addressed this partly by design, every event gets normalized into a standard schema: message, description, author, timestamp, files changed, PR state.

The AI reasons over structured data, not just raw commit messages. PR descriptions especially help. Most devs write oneline commits but actually explain context in the PR body. We capture that.

Still, teams with good commit hygiene get better output. No way around it.

Appreciate the thoughtful take.