How CyberMinds Built a Living Project Brain in 3 Runs
A student-run cybersecurity nonprofit went from scattered DMs and vague notes to shipping full features with CI pipelines, async workflows, and zero missed deadlines in 3 Ryva runs.
By Ege Uysal
They couldn't answer what was done, what was blocked, or what mattered next.
CyberMinds is a student-run nonprofit building a cybersecurity education platform with CTF challenges and a learning portal. The team is distributed across time zones, shipping real software under real constraints, and trying to move quickly without losing control of project state.
We would be genuinely upset if Ryva didn't exist.
That was not feature feedback. It was a team saying the system had become load-bearing for how they operate.
Before Ryva, the work was happening, but visibility was fragmented. Project status lived in a Word doc that drifted out of date. Progress updates were buried in WhatsApp threads. Ownership decisions often happened in DMs, invisible to everyone else. Information existed, but there was no reliable way to answer what was done, what was blocked, and what mattered next.
That created predictable failure modes: unclear ownership, uneven code quality, and missed deadlines caused by state blindness rather than lack of effort.
The moment things broke
The turning point came during work on their CTF challenge feature. The team realized they were likely to miss the deadline and could not explain exactly why. When they mapped remaining work, they hit the same pattern again: stale notes, fragmented chat context, and tasks that were clearly important but not clearly owned.
There was no single place to look, so they ran Ryva for the first time.
Run 1: making the problem undeniable
The first run did more than summarize activity. It assembled project reality in one place and made the root issue hard to argue with. Ryva pulled from GitHub and WhatsApp, mapped backlog and ownership, and exposed the same three gaps everyone had been feeling:
- stale or vague documentation
- fragmented communication
- no persistent owner-level accountability
The issue was not effort. The issue was missing shared state.
That made the next move obvious. They stopped treating docs and chat as the execution source of truth, and shifted coordination into GitHub Issues where ownership and follow-through were explicit.
Runs 2 and 3: from insight to operating habit
By run 2, they were not just reading output. They were executing from it.
On March 26, Ryva generated four concrete GitHub Issues:
- backend unit tests with a CI coverage gate at 60%
- ESLint (Airbnb) plus frontend CI enforcement
- quarterly Go and Node version upgrade policy
- recurring async status workflow as GitHub Issues
Those gaps were known before, but informal. Ryva converted them into owned work.
By run 3, adoption became habitual. Aarohi, the team lead, was running Ryva herself and sharing links proactively. At that point, Ryva stopped behaving like a helper and started behaving like infrastructure.
What changed in the codebase
In the six weeks after the first run, CyberMinds shipped 34 commits and 7 PRs to main, implemented a full CI baseline (backend build checks plus frontend lint enforcement), and launched privacy-safe analytics via Umami without major blockers.
They also shipped operational improvements that compound over time:
- weekly GitHub bot to auto-create status issues from Ryva output
- server-side challenge progression enforcement for the CTF flow
- 1 new teammate onboarded and contributing in the same week
They replaced their recurring status meeting with async execution. Progress now lives in auto-created GitHub Issues, and synchronous meetings happen only when ambiguity is high enough to require live negotiation.
What Ryva tracked in the last seven days
Recent run metrics show the operating shift clearly:
- 9 decisions captured in 7 days
- 82% decision resolution rate (23/28 resolved)
- 100% of runs referencing top-priority context
- about 2 hours reclaimed in 1 week from avoided standups
Instead of resetting every cycle, context carried forward between runs. Signal accumulated, and the team moved faster with less coordination overhead.
In their own words
When asked about Ryva, Aarohi's response was immediate:
This is absolutely amazing.
When the team discussed canceling their next meeting, the answer was equally direct:
Ryva already surfaced what needs to happen.
That line is the clearest proof point. The tool moved from useful to essential in their operating model.
What this means for your team
CyberMinds is not a large org with heavy PM process. It is a student team building real software with distributed availability, limited formal structure, and high delivery pressure.
If your team still needs recurring meetings just to reconstruct project state, that is the bottleneck.
Ryva did not require a process overhaul here. CyberMinds ran it, reviewed output, executed next actions, and repeated. Three runs later, the workflow became default.
Want me to run this on your repo and show you what it finds? Reach out at ryva.dev/about.