An autonomous, privacy-preserving developer-identity aggregation network with live data synchronization.
One developer. Ten platforms. A single living, verified portfolio.
🌐 Live production instance · 🎬 2-minute demo · 🧱 Architecture · 🔐 Security model
Note on this repository. This is the public case-study shell for DevIdentity. The production application source — parsing engines, prompt systems, UI system, and database schemas — is proprietary and lives in a private repository under a strict all-rights-reserved license. This document explains what was built and why the architecture works, without exposing protected implementation detail, credentials, or private route logic.
A developer's professional identity in 2026 is fragmented, static, and unverifiable:
| Pain | Reality |
|---|---|
| Fragmentation | Repos on GitHub, notebooks on Kaggle, models on Hugging Face, papers on arXiv & Google Scholar, contest ratings on LeetCode, a résumé on LinkedIn — no single surface tells the whole story. |
| Staleness | Portfolios are hand-built once, then rot. The gap between "what the portfolio says" and "what the developer shipped last month" only grows. |
| Genericity | Most portfolios are repo mirrors or template pages — star counts and boilerplate bios, with zero narrative about actual engineering depth. |
| Zero verification | Recruiters and hackathon judges have no way to know whether showcased code was authored by the candidate, forked, or copied. Trust is asserted, never demonstrated. |
DevIdentity is an autonomous aggregation network that:
- Connects to 10+ platforms through two ingestion pipelines — native APIs where they exist, and a consent-based, user-driven capture flow where they don't.
- Normalizes every source into one universal identity model, so core logic never learns platform-specific shapes.
- Analyzes the aggregate with an evidence-only AI layer that scores genuine technical depth (independent of stars) and writes a professional narrative that must cite real projects — never invent.
- Publishes a fast, animated public portfolio that keeps itself current as the developer ships.
- Verifies — a recruiter-facing Judge Console runs fork-provenance and commit-authorship checks against public GitHub contributor statistics, plus AI job-alignment reports where every matched requirement cites the specific project it came from.
flowchart LR
subgraph Sources["Identity Sources"]
GH[GitHub<br/>OAuth + REST]:::api
API[Kaggle · HF · LeetCode<br/>arXiv · Dev.to …]:::api
ING[LinkedIn · Scholar<br/>consent-based capture]:::ingest
end
GH --> SYNC[Sync services<br/>content-hash diffing]
API --> SYNC
ING --> PARSE[AI ingest parser<br/>injection-guarded]
SYNC --> DB[(Postgres<br/>strict RLS)]
PARSE --> DB
DB --> AI[Provider-agnostic AI layer<br/>primary → automatic fallback]
AI -->|depth scores · case studies · narrative| DB
DB --> NORM[Universal identity<br/>normalizer]
NORM --> PORTFOLIO[Public portfolio]
NORM --> DASH[Owner dashboard]
NORM --> JUDGE[Judge Console<br/>verification layer]
classDef api fill:#1c1622,stroke:#c2a4ff,color:#eae5ec;
classDef ingest fill:#1c1622,stroke:#a87cff,color:#eae5ec;
1 · Monorepo discipline (Turborepo + pnpm) Apps and shared packages live in strictly separated workspaces: the Next.js 16 App Router application, a standalone portfolio renderer, a shared types package (the single home of every domain type), and shared lint/TS config. Pure logic and I/O never share a file — every domain keeps a dependency-free pure module and a separate server module, eliminating the entire class of "server import leaked into a client bundle" failures.
2 · Two-pipeline ingestion with graceful degradation Every platform is classified by how its data can be obtained. Platforms with real APIs sync natively. Platforms without (LinkedIn, Google Scholar) go through a consent-based capture flow — the user supplies their own profile, and an injection-guarded LLM parser maps it into the same normalized records, never fabricating data. When neither is possible, the UI degrades to an honest, polished link card — a broken zero is never rendered as real data.
3 · The universal identity model All sources normalize into one internal shape before anything consumes them. Core logic — AI analysis, portfolio rendering, the Judge Console — never learns about individual platforms. Adding a source is one registry entry plus one normalizer function.
4 · Defensive server-side gating Middleware is the page gate (explicit public allowlist; everything else redirects). Every API route independently re-verifies the session and resolves entitlements from the database — never from a client-supplied value. Client-side premium gates are purely presentational; the server gate is the law.
5 · Provider-agnostic AI with automatic fallbacks Feature code never imports a vendor SDK. A single generation layer routes to the configured primary model and falls back automatically on any failure — features keep working regardless of which provider keys exist. Every persisted AI output is stamped with the concrete model ID and a prompt version, so quality regressions are debuggable and rubric upgrades retroactively re-score.
6 · Verification as a first-class feature The Judge Console grades commit authorship against GitHub's public contributor statistics (✅ Primary author · 🟡 Contributor · 🔴 No authorship trace) and badges fork provenance directly on portfolio cards. Graded, neutral signals — never accusations.
| Surface | What it delivers |
|---|---|
| Public portfolio | Animated, mobile-responsive identity site — AI headline & narrative, skills matrix, works segmented by originating platform, provenance badges. Viewable logged-out, SEO/OG complete. |
| Owner dashboard | Integrations hub, sync health, analytics, AI insights, editable AI-generated fields (every generated field is user-editable before going public). |
| Judge Console | Recruiter-side: paste a job description → evidence-cited match report; one-click code-authenticity checks over showcased repos. |
| Admin console | Owner-pinned operations: usage metering, sync health, user lifecycle (suspend / soft-delete), AI cost monitoring. |
| Billing | Free / Pro / Premium tiers via Stripe checkout → signature-verified webhook → server-resolved plan. The webhook is the only writer of paid state. |
Security posture is architectural, not bolted on. The concrete implementations are proprietary; the guarantees are public:
- Strict Postgres row-level security — three isolated database client roles (session-scoped, browser-anon, and a server-only service role that can never reach a client bundle).
- Defense in depth — middleware gates pages; every API route independently re-verifies the session and re-resolves entitlements server-side.
- Consent-respecting data loading — items the owner hides never load, not merely never render. Visibility filtering happens at the data loader, upstream of every consumer including AI prompts.
- Two-direction prompt-injection guarding — all untrusted text entering an LLM (user input and third-party content) is sentinel-delimited, length-capped, and explicitly declared as data-not-instructions.
- Automated, token-backed rate limiting — per-user, per-endpoint daily quotas with full usage attribution (endpoint, tokens, model), doubling as the admin analytics source.
- Signature-verified webhooks — raw-body signature checks before any payload field is read; cron surfaces require a shared secret.
- Hardened response headers — CSP with
frame-ancestors 'none', nosniff, frame-deny, strict referrer policy, and locked-down permissions policy on every response. - Zero secret exposure — server env vars never reach client code; every build-time variable is explicitly declared for cache correctness. This document and this repository contain no credentials, no private route logic, and no schema dumps.
| Layer | Choice | Why |
|---|---|---|
| Framework | Next.js 16 (App Router) + React 18 + TypeScript | Server components, streaming, one deployable surface for app + public portfolio + API |
| Monorepo | Turborepo + pnpm workspaces | Shared types/config as first-class packages; remote-cache-correct builds |
| Data & auth | Supabase (PostgreSQL + strict RLS + Auth, PKCE OAuth) | Row-level security as the data-access floor; native + Google sign-in |
| AI | Provider-agnostic layer — Gemini primary, Groq (Llama 3.3 70B) automatic fallback, Claude available for premium tasks | Model choice is a config value, not an architecture decision |
| Payments | Stripe (checkout · portal · webhook) | Webhook as the single writer of paid state |
| Observability | Sentry (env-gated: wired but inert until its DSN exists) | Feature-flag-by-env-presence pattern |
| Hosting | Vercel, git-connected, custom domain | Push-to-deploy; canonical URL in exactly one env var |
▶ Watch the 2-minute walkthrough — signup → connect GitHub → AI analysis → live portfolio → Judge Console verification.
- Zero-downtime schema evolution — additive, nullable migrations only; code ships defensive-first so a deploy never depends on a migration having landed.
- Cost-engineered AI — content-hash diffing skips re-analysis of unchanged work; cheap validity preconditions run before any paid call; hard input caps bound every prompt.
- Malformed-output salvage — a JSON repair ladder recovers truncated or fence-wrapped model output instead of failing the request; everything is defensively normalized (clamped, whitelisted, sliced) before it reaches the UI.
- Immutable, actor-attributed verification — authenticity verdicts are cached with timestamps on the records they describe, graded against public contributor data, and never expressed as accusations.
- A launch-runbook culture — every manual operational step (domain cutover, OAuth registration, webhook rotation, SMTP) is written down as a numbered runbook section the day it's discovered.
| 🌐 Live production | devidentity.fabbythemes.com |
| 💼 Builder | Abu Ahmad — GitHub @abuahmad369 · LinkedIn |
| 🔌 Public integration guide | SDK-PUBLIC-README.md |
| 📬 Licensing & enterprise inquiries | abuahmad105116@gmail.com |
© 2026 DevIdentity. All rights reserved.
The DevIdentity application source, parsing engines, prompt systems, UI system, and database schemas are proprietary. See LICENSE. This case study may be shared; the product may not be copied.