Project Info
Inspiration
We realized that a person’s GitHub says more about them than any dating profile ever could—commit history, README vibes, even that one cursed 2 AM push. So why not let the code do the talking? With gitRizz.ai, we’re turning repositories into relationships, because nothing says “soulmate” like burnout and a mutual obsession with clean code ❤️
What it does
gitRizz.ai is a Hinge-style matchmaking platform that curates GitHub profiles to find the most optimal matches - all you have to do is login with Github! We generate vector scores for each user, combining numerical metrics (commits, contributions, PRs) with contextual analysis (commit messages, READMEs, bios, profiles) to get a well-rounded view of their personality from both their technical contributions and textual expressions of themselves. Using vector search, we calculate similarity scores between users, ensuring meaningful connections. Lastly, we used OpenAI to generate personalized feedback for each profile since a lot of these Github profiles can have a lot of information all at once. If two users mutually swipe right, they can chat and collaborate—professionally or romantically!
How we built it
Backend: We used the Github API and beautiful-soup to scrape most public data from a user’s profile—including their picture, READMEs, bio, and so on. We consolidate all the quantitative contributions of the user (number of contributions, commits, pull requests, PRs, etc.) as well as an analysis of their textual contributions such as the commit messages, READMEs, and PR content. Using OpenAI API, we are able to generate an 6-dimensional vector representing their characteristics ranging from commitment to collaboration style. Finally, using a cosine-similarity matching algorithm, we are able to generate an list of potential matches to show a specific user. Frontend: Firebase + Github authentication, and from there, it was all React + JavaScript + Flask.
Challenges we ran into
For future scalability, it is important to minimize expensive API calls. At first, our output was generated way too slowly as calls were made repeatedly. Instead, by caching users vectors, we are able to reduce computation significantly. In the future, we would likely be able to utilize an ML algorithm that can perhaps avoid such calls for certain users all together and instead infer potential matches more indirectly (ex: A and B are a good match and A and C are a good match, so maybe B and C are a good match.) Also, deciding what metrics to hone in on was a challenge, one that we are still working on.
Accomplishments we're proud of
We wanted the UI to highlight just how much of the work we do for you - after all, all you do is login with Github and we calculate everything from there. Thus, the interface had to be simplistic, modern, yet easy to understand and use when it came to finding matches and prospective candidates. Mapping this out and narrowing down on a design was difficult but worthwile. Also, we’re proud of simply ideating this project, which is the perfect balance of silly and serious. Beyond classes and random cool hackathon encounters, there really isn’t a systematic tool for meeting devs with a similar vibe as you!
What we learned
Designing for scale from the beginning is important! Caching user data from the start would’ve made life so much easier. Also, sometimes, the best ideas come from silliness—this was inspired by Valentine’s Day!
What's next
Adding more metrics on which to match people on. Adding more text and video prompts. Allow users to filter by platonic or romantic, sexuality, distance, etc. Reward and boost users who contribute to open-source repos, are rated well by peers, etc. Building out the chat + post-match interface. We wanted to focus on profile curation + statistics, so didn't implement this portion for the hackathon.
Analysis
View
Metric
- 10
- 8
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- FirebaseIn code
- HTMLIn code
- JavaScriptIn code
- PythonIn code
- ReactIn code
- Tailwind CSSIn code
- FlaskClaimed
- Node.jsClaimed
- OpenAIClaimed
7 of 10 appear in the indexed code. 3 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
91 KB
Source files
20
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
aliceli465/treehacks25
35 files · 1.4 MB · @ 9f125a4
Structure
Interface
7 files · 20%Screens, components and styles rendered to the user.
Application logic
9 files · 26%Domain rules, services and shared utilities.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- JavaScript61%
- Python23%
- CSS11%
- Markdown4%
- HTML2%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
gitrizz/package.json
npm · 24- @chakra-ui/react
- @emotion/react
- @emotion/styled
- @tailwindcss/postcss
- @tailwindcss/vite
- @testing-library/dom
- @testing-library/jest-dom
- @testing-library/react
- @testing-library/user-event
- cors
- firebase
- framer-motion
- lucide-react
- react
- react-dom
- react-icons
- react-router-dom
- react-scripts
- +6 more
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.