DevRank

DevRank is a project that targets developers worldwide to encourage them to get back into learning and developing while solving real-world problems with tech solutions. Bringing back the fun in coding

Comment

Inspiration

I have watched too many developers, including myself, lose momentum. You finish a tutorial, build a to-do app, and then just... stop. Not because the passion is gone, but because you do not know what to build next, and nobody is holding you accountable.

DevRank started as a simple question: what if your GitHub commits were your score? What if there was a leaderboard that made consistent development feel like a game worth playing, and an AI that told you exactly what to build next based on where you actually are, not where some generic tutorial assumes you are?

Many developers and people eager to become programmers have lost the urge to build. DevRank exists to bring that drive back.

What it does

DevRank is a gamified developer leaderboard powered by Auth0, GitHub OAuth, and an AI agent.

  • Developers log in via Auth0 (Google or email)
  • Connect their GitHub account, with the token stored securely in Auth0 Token Vault
  • Get ranked on a weekly leaderboard by real commits across all owned, non-forked repositories
  • Request an AI-generated roadmap of 3 personalized next projects based on their tech stack, experience level, and recent activity

The AI agent analyzes your GitHub profile, languages used, commit frequency, and repository count, classifies your experience level as Beginner, Intermediate, or Advanced, and calls an LLM via OpenRouter to generate practical, tailored project suggestions. Those suggestions are stored locally so the dashboard loads instantly on every visit. The AI is only called when you deliberately ask for new suggestions, keeping API costs minimal and the experience fast.

How I built it

The stack is intentionally minimal:

  • Flask: backend routing, Jinja2 templates, SQLAlchemy ORM
  • Auth0 + Authlib: OpenID Connect authentication via server_metadata_url for clean auto-discovery
  • Auth0 Token Vault: secure GitHub token storage via the Management API and OAuth 2.0 Token Exchange (RFC 8693)
  • GitHub REST API v3: paginated contribution data across all owned, non-forked repositories
  • OpenRouter + Mistral: AI roadmap generation with a 3-model fallback chain for reliability
  • SQLite: lightweight persistence for users, GitHub usernames, and stored roadmap suggestions
  • Bootstrap 5: dark theme UI with a glassmorphism auth card (not very visible on the background) and responsive grid

The architecture follows one principle: only call external APIs when absolutely necessary. GitHub data is cached with a 1-hour TTL. AI suggestions are stored in the database and only regenerated on explicit user request. Token Vault retrieval has a DB fallback. Every external dependency has a graceful failure path.

Challenges I ran into

Auth0 Was Humbling

I came into this hackathon with minimal OAuth experience. The first real wall was a *callback URL mismatch, Auth0 kept rejecting my redirect URI. After hours of debugging, I found that hardcoding redirect_uri inside oauth.register() competed with the dynamically generated one from Flask's url_for(). Removing that one line fixed everything.

The second wall was session persistence. Users logged in successfully but arrived at the dashboard as None. The culprit was SECRET_KEY = os.urandom(24) in my config, it regenerated on every Flask restart, invalidating every session. I had left it there and forgotten aboutit. A fixed value in .env resolved it immediately.

The third wall was the two-tenant problem. I had accidentally configured my Auth0 applications across two different tenants without realizing it. My .env pointed to one domain, my Auth0 dashboard was open on another.

Every permission I set was on the wrong tenant. It took a full teardown and rebuild from scratch, on a single confirmed tenant, to get everything aligned.

Token Vault Was a Different Level

Getting Token Vault working required:

  • A Regular Web Application with Token Vault grant type enabled
  • A separate Machine to Machine application for the token exchange
  • Correct Management API permissions on the M2M app: read:users, update:users, read:users_app_metadata, update:users_app_metadata
  • URL-encoding the Auth0 user ID, google-oauth2|123 must become google-oauth2%7C123 because the pipe character breaks the Management API URL

The 403 errors I kept hitting were caused by the wrong tenant, missing grant types, and unencoded user IDs, all at different times, all looking identical in the logs.

The AI Free Tier Problem

The OpenRouter free tier models returned 404 errors consistently, no available endpoints. Rate limits on remaining free models made them unusable for a live demo. The solution was simple: top up $5 in OpenRouter credits.

The catch was timing. I discovered this late at night with no way to add funds immediately.

I had to wait until the next morning, deposit money at the bank, and buy credits before I could continue. That overnight delay forced me to think more carefully about the AI service architecture, which is how the 3-model fallback chain, strict JSON validation, and DB-cached suggestions all came to exist. The constraint made the solution more robust than it would have been otherwise.

Accomplishments that I am proud of

  • Successfully integrating Auth0 Token Vault as a complete beginner to OAuth, understanding not just how to use it but why it matters for security
  • Building a graceful fallback architecture throughout, Token Vault falls back to DB storage, AI models fall through a chain of alternatives, GitHub errors never crash the leaderboard
  • Designing an AI cost optimization pattern, storing suggestions in SQLite and only calling the AI on explicit user request, reducing API calls to the absolute minimum without sacrificing the feature
  • Shipping a working, end-to-end application as someone new to both OAuth and AI agents, under real deadline pressure (Not shipped yet but my go to would be Render free tier)

What we learned

I still have a lot to learn, but I learned a great deal about Auth0 and the security behind the applications, tools, and technology we use every day.

From a development perspective, I will never again start a project without considering authentication and authorization from day one. Auth0 and OAuth are not optional extras, but are foundational, and getting them wrong has real consequences.

I learned how to create and configure applications inside Auth0, how to choose permissions deliberately, and how one misconfigured grant type or one unauthorized M2M client can be the difference between a working. Token Vault and hours of 403 errors.

I learned that fallback architecture is not pessimism, it is engineering. Every external dependency in DevRank has a graceful failure path, and that made the difference between a broken demo and a working submission.

And I learned that the best way to understand OAuth is to break it, fix it, break it again, and fix it again, preferably under deadline pressure.

What's next for DevRank

Shipping, definitely shipping and see if developers love it. but first, keep learning and continue to:

  • Full Token Vault integration with resolved M2M permissions across all environments
  • Streak tracking: Consecutive days with at least one commit
  • Badge system: Milestones for commit counts, languages used, and consistency
  • Invite system: Share a link to bring peers onto the leaderboard
  • Extended AI context: Include pull requests, issues closed, and code review activity for a richer experience level classification
  • Production deployment with HTTPS, secure session cookies, and a persistent database

Built With

Share this project:

Updates