Git-RepoIntel
What Git-RepoIntel solves
Git-RepoIntel is an AI-powered intent intelligence platform that converts public engineering activity into revenue opportunities for technical product teams. Instead of relying on weak and noisy signals like ad clicks, form fills, whitepaper downloads, or LinkedIn activity, Git-RepoIntel looks at what companies are actually building in public on GitHub and turns that into actionable buying intent. The idea is simple: engineering decisions usually happen before purchase decisions, so if a company is changing infrastructure, adopting new tooling, expanding teams, or improving security, that movement can be a much stronger signal than traditional lead-gen methods.
We built this project because sales, growth, product, and security teams need earlier and better visibility into which companies are likely to buy. Git-RepoIntel is designed to help them find hot leads, score account priority, track engineering signals, and revisit intelligence later instead of treating every company scan as a one-time lookup.
How we used MeDo
We used MeDo as the product-building layer for everything the user sees and interacts with: the SaaS shell, the dashboard, the control panels, the navigation, the cards, the loading states, the empty states, the analysis history, the watchlists, the alerts, the reports, and the overall user experience. We structured our conversations with MeDo in a module-by-module way, starting from product foundation, then UI shell, then authentication and persistence, then backend data fetching, then signal filtering, then AI intelligence, and finally orchestration and dashboard binding. That stepwise approach helped us avoid building a scattered prototype and instead shaped the app into a coherent SaaS product.
MeDo was especially useful because it could rapidly turn our prompts into a visible product structure. In the early stages, it generated the dashboard shell, the Analyze Company page, watchlists, alerts, reports, settings, and the supporting UI states. Those first mock-data versions were important because they let us define the visual hierarchy and user flow before the backend was fully complete. After that, we kept iterating with tighter prompts to improve layout, persistence, error handling, mobile behavior, and data binding.
The best part MeDo generated
The strongest thing MeDo generated was the premium SaaS experience around the intelligence. It did not just give us a form and a button; it helped us shape a real product surface with a hero insight card, recent analyses, watchlists, alerts, reports, and a visually rich dashboard that made the signals feel valuable. That visual intelligence layer was crucial because our product is not about displaying raw GitHub data — it is about translating engineering behavior into business meaning that a revenue team can act on.
Another standout was how MeDo handled the product structure around memory and action. The app was designed to support saved analyses, watchlist monitoring, alerts, reports, persistence, and recurring intelligence instead of a one-off scan. That made the project feel like a living platform, not a static demo.
How the backend and AI intelligence layer work
To power the product, we connected the frontend to a backend pipeline that accepts a GitHub organization, keywords, business context, and industry, then returns structured intelligence back to the UI. The backend process was intentionally designed in stages: first raw GitHub data, then signal filtering and preprocessing, then the AI intelligence layer, then orchestration back to the dashboard. That approach matched the build checklist we followed and helped us keep the product grounded in real evidence.
The most impressive integration detail is that we kept refining the request and response schema as the project evolved. When we changed the prompt shape, the backend output format, or the fallback behavior, MeDo was able to adapt the UI to match. That meant the product stayed consistent even as the intelligence layer became more sophisticated. We also added clear fallback behavior for invalid GitHub orgs or URLs so the app could respond gracefully instead of breaking.
Why the product matters
GitHub activity is powerful because it often reveals what a team is changing before a buying decision is obvious. A company adding Kubernetes, changing frameworks, increasing contributor activity, or creating new infra-related repos may be telling you something important about where the company is heading. Git-RepoIntel was built to detect exactly those patterns and surface them as buying signals for the teams that need that insight most.
This is why the product has a strong fit across multiple user groups: sales teams can find accounts in motion, growth teams can identify market shifts, product teams can learn what technologies are gaining traction, and security vendors can detect changes in a company’s security posture.
The Signal Types We Detect
| Engineering Signal | Business Interpretation |
|---|---|
New repos named platform, infra, security |
New investment area opening — tooling decision incoming |
| Kubernetes, Helm, or service-mesh activity | Container adoption — needs observability, cost, security layer |
| Auth, OIDC, RBAC, secrets activity | Security hardening or compliance initiative underway |
| Terraform, Pulumi, or CDK adoption | Cloud infrastructure expansion — budget committed |
| LLM, inference, embeddings repository topics | AI product development — GPU and serving infrastructure needed |
| Contributor count surge + new repositories | Team scaling — budget increased, buying window open |
| Observability tool topics across multiple repos | Stack investment — active evaluation in progress |
| Data pipeline, dbt, Kafka, warehouse keywords | Data platform modernisation — tooling gaps exist |
The challenges we faced
One of the biggest challenges was noise versus signal. GitHub is full of commits, updates, and maintenance activity that are not meaningful buying signals. The product had to learn how to filter out weak noise like generic updates, typos, bumps, and cleanup work, then focus on stronger signals like migrations, infrastructure changes, security-related updates, and broader activity patterns. That challenge is a core part of why the product is valuable: it does not just collect GitHub data, it interprets it intelligently.
Another challenge was false positives and product-builder behavior. Some companies are not buyers of the technology they appear to be “using” — they are the ones building it. We had to account for that in the AI reasoning so the platform could distinguish between a true buyer opportunity and a potential partner or competitor situation. That made the recommendations more honest and commercially useful.
We also had to iterate many times because MeDo did not always get everything right on the first pass. Some layouts needed rework, some behaviors needed better persistence, and some UI states needed to be scoped more carefully. Instead of treating that as a failure, we used it as part of the build process: we refined our prompts, clarified the structure, and pushed the app closer to production behavior step by step. That iterative conversation pattern became one of the most useful parts of the build.
What we are most proud of
We are especially proud that Git-RepoIntel now feels like a real SaaS product, not just a demo idea. It has a defined product story, a dashboard, an analysis flow, persistence, watchlists, alerts, reports, history, and a structured intelligence engine. The project moved from a concept into a complete user journey where someone can sign in, analyze a company, review the evidence, save the result, and come back later to see the history and updates.
We are also proud of how the app’s intelligence became more actionable over time. The output is not just “something happened on GitHub”; it is a clear recommended action, urgency, confidence, and evidence trail that a sales or growth team can actually use. That transformation from raw data to commercial insight is the heart of the project.
What we learned
This build taught us that good product design is not just about UI, and good AI is not just about prompts. The best result came when we combined both: a clean SaaS experience from MeDo and a tightly grounded intelligence pipeline from our backend. We also learned that structured iteration matters. By breaking the product into modules, we could solve one layer at a time instead of trying to build everything at once.
We also learned that product trust comes from clarity. Clear labels, evidence, fallback states, persistent history, and honest recommendations made the system feel more credible. That mattered just as much as the core analysis itself.
What is next for Git-RepoIntel
After the hackathon, the next step is to keep improving the intelligence engine and make the monitoring even smarter. We want to deepen watchlist automation, expand signal history, strengthen alerting, and continue refining the reporting layer. We also considered future database migrations and cloud-native persistence improvements, but for this build we prioritized shipping a complete, working product first.
Git-RepoIntel is now positioned as a living intelligence platform that helps teams detect buying signals early, act faster, and make better decisions from public engineering behavior.
Final note
Git-RepoIntel started as an idea about reading buying intent from GitHub, but through MeDo, backend orchestration, and repeated refinement, it became a real multi-module SaaS experience with intelligence, memory, and action at its core. That is the version we are excited to submit.
Built With
- gemini
- google-cloud
- medo
- postman
- python
- supabase
Log in or sign up for Devpost to join the conversation.