resources

← prev · next →

Top 8 email copy

Top 8 email copy

Date: 2026-04-12

Use:

  • send as email, not DM
  • only use repo-run line if you actually ran it on their public repo
  • if no public repo, delete that paragraph
  • if no verified founder email, use hello@, founders@, or site contact form

1. Guillaume Marquis, Basalt

Subject: loved your take on eval loops at Basalt

Hi Guillaume,

I recently came across your post about eval loops still being heavy, slow, and boring, and I loved how clearly you framed it. “Most people don’t like running evals” is one of those lines that immediately tells me you’ve lived the pain, not just observed it from outside.

I know that pain personally. In small technical teams, the visible problem looks like evals or review speed, but the underlying issue is usually that project state is scattered across PRs, docs, Slack, and people’s heads, so every sync turns into reconstruction.

That is exactly why we built Ryva. It makes owner, blocker, decision, and progress state visible while work is happening, instead of forcing the team to manually reconstruct it in standups and status threads.

Optional repo-run paragraph. Only use if true: I also ran Ryva against one of your public repos, and it surfaced [specific issue] around [ownership / blocker / review / stale thread]. If useful, I can send over the exact view.

If you want to take a quick look, happy to share it here or hop on a short call: https://cal.com/egeuysall/chat

Source:

2. Alexandre Berkovic, Sphinx

Subject: your “headcount while you wait” line was sharp

Hi Alexandre,

I recently stumbled across your post about compliance tools costing “headcount while you wait,” plus the engineering time required to maintain them, and I loved how specific it was. That line is unusually good because it captures the hidden operating tax, not only the tool spend.

I know that pain personally. In early technical teams, the visible problem might look like compliance, approvals, or delivery delays, but underneath it is often fragmented project state: no clean view of owners, blockers, or decisions, so coordination becomes expensive.

We built Ryva for exactly that. It gives small teams one visible operating layer for ownership, blockers, and decision history, so less time gets burned reconstructing status across Slack, Jira, PRs, and docs.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [decision drift / stale ownership / review bottleneck]. Happy to send the link if useful.

If you want to see it, happy to share or jump on a quick call: https://cal.com/egeuysall/chat

Source:

3. Steve Ancheta, Zig.ai

Subject: your “6-8 tools, none talking” post felt very real

Hi Steve,

I recently read your post about teams running six, seven, eight tools that do not talk to each other, and I loved how direct it was. That line is dead-on because fragmentation is usually not just a GTM problem; it bleeds straight into engineering coordination too.

I know that pain personally. Once state is spread across too many systems, you get PR drift, Slack blockers, stale Jira, weak ownership, and standups that mostly exist to reconstruct what is already supposed to be known.

We built Ryva for that exact failure mode. It gives small technical teams a live view of owner, blocker, decision, and current state without adding yet another layer of admin.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [unclear ownership / stale planning / review delay].

If useful, happy to share it or walk through it quickly: https://cal.com/egeuysall/chat

Source:

4. Rohan Katyal, Milana

Subject: your point on agents lacking team priorities was spot on

Hi Rohan,

I recently came across your point that agents fail when they do not have user behavior, business metrics, and team priorities, and I loved how you framed it. That is one of the clearest expressions of invisible operational state I’ve seen.

I know that pain personally. The moment team priorities and ownership are real but not visible, every sync becomes archaeology. Humans suffer first, then agents do too.

That is exactly why we built Ryva. It gives teams one visible thread for priorities, blockers, and decisions, so state is not trapped in founders’ heads, PRs, docs, and Slack.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [priority drift / owner ambiguity / blocker pileup].

If you want to check it out, happy to send it over or hop on a quick call: https://cal.com/egeuysall/chat

Source:

5. Chrisjan Wust, Sphinx

Subject: “months-long backlog in a day” caught my eye

Hi Chrisjan,

I recently came across your comment about watching a customer clear a months-long backlog in a day, and I loved that framing because it points to real workflow compression, not vanity efficiency.

I know that kind of pain personally. When teams have work spread across embedded tools, review queues, and approval paths, the team can move quickly in bursts, but internally a lot of time still gets lost on status recovery and ownership confusion.

That is exactly the gap we built Ryva for. It keeps decisions, blockers, and owners visible as work moves, so teams do not need a meeting to recover shared context.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [handoff / stale PR / unclear owner / review queue]. Happy to send that view over.

If useful, here is my calendar: https://cal.com/egeuysall/chat

Source:

6. Akshay Chalana, Saphira AI

Subject: loved your post on AI in functional safety

Hi Akshay,

I recently stumbled across your post on AI in functional safety, especially around tool qualification, risk analysis, technical documentation, and standards, and I loved it. It was specific enough that it clearly came from real engineering pain.

I know that kind of pain personally. In systems like that, the code is only part of the problem. The bigger drag is that requirements, docs, tests, approvals, and decisions are spread across too many places, so state is never truly visible.

That is exactly why we built Ryva. We are not replacing compliance tooling, but we do make decision, blocker, and ownership state visible so teams stop losing time to reconstruction.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [requirements drift / unclear owner / stale review loop].

If useful, happy to share or jump on a quick call: https://cal.com/egeuysall/chat

Source:

7. Bastien Beurier, Nango

Subject: your PRPM post hit exact problem we care about

Hi Bastien,

I recently came across your post on PRPM and loved it. The part that stood out was not the acronym, but the fact that it came from a real need to teach LLMs the quirks of hundreds of APIs and preserve team knowledge in a reusable way.

I know that pain personally. Once critical knowledge lives across people, issues, docs, and Slack threads, review and coordination get slower every cycle even when the team is strong.

That is exactly why we built Ryva. It gives teams one visible operational thread for decisions, owners, blockers, and context, instead of relying on tribal memory.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [context fragmentation / review drift / hidden blockers].

If useful, I can send the link or walk through it quickly: https://cal.com/egeuysall/chat

Source:

8. Caroline Walerud, AirForestry

Subject: your “disciplined engineering” note felt timely

Hi Caroline,

I recently read your note on AirForestry entering a decisive phase with disciplined engineering, field validation, and building a machine platform that can scale, and I loved how grounded it was. That is exactly the kind of transition point where coordination friction gets expensive.

I know that pain personally. Once a team starts moving from early build mode into disciplined execution, hidden project state becomes one of the biggest sources of delay.

That is why we built Ryva. It keeps owner, blocker, and decision state visible while the work is happening, so teams do not need to rebuild shared context every week.

Optional repo-run paragraph. Only use if true: I ran Ryva against one of your public repos and it surfaced [specific issue] around [handoff / dependency / blocker visibility].

If useful, happy to send it or walk through it here: https://cal.com/egeuysall/chat

Source: