Step 1 — what's the goal?

This isn't just a tech-debt scanner — the more we know about what you're actually trying to do, the more useful the report gets. Pick the closest fit; you can change it any time.

Step 2 — give it more context (optional, not built yet — see below)
▾ show what's planned

A confidence score from code alone is only part of the picture. A modernization plan gets meaningfully better with the context that already exists elsewhere — a Jira ticket explaining why a module is a mess, a Confluence page with the original design intent, a ServiceNow change record showing what broke last time someone touched it. None of the sources below are connected yet — this is the roadmap, shown honestly as not-yet-built, not a working integration.

📘 Confluence — coming soon

Would pull existing design docs and runbooks to cross-reference against what the code actually does — catching cases where the docs and the code disagree.

🎫 Jira — coming soon

Would surface open tickets and known-issue history tied to the riskiest files, so a low confidence score comes with "and here's why, per the team that touched it."

🛠️ ServiceNow — coming soon

Would pull change and incident history — which files have caused production issues before is a real risk signal code structure alone can't see.

📁 SharePoint — coming soon

Would ingest design documents and runbooks already written internally, instead of starting the assessment from zero context.

🗺️ Lucidchart / draw.io — coming soon

Would read an existing architecture diagram and check it against the dependency graph greybox builds from the actual code — flagging where the diagram and the code disagree, not just displaying both side by side.

What that finding would look like — this is a fabricated example to show the shape of the output, not a real scan result. No diagram was actually read.

MOCKUP — ILLUSTRATIVE ONLY, NOT REAL OUTPUT
billing/reconcile_ledger.py
confidence: 41% — low

Diagram vs. code: your draw.io diagram shows reconcile_ledger calling only ledger_db. The actual code also calls notifications_service directly — a dependency the diagram doesn't show.

Confluence vs. code: the design doc says reconciliation runs "nightly, batched." The code runs it synchronously on every request — no batching found.

From code alone: bare except: block at line 118, no comment explaining why.

Suggested next step: confirm with whoever owns billing whether the notifications call is intentional — it's a real production dependency that isn't in either the diagram or the docs.

Want one of these prioritized? Tell us which →

Step 3 — scan your code
See a sample report first →

Scans up to 100 files per repo (Python, Java, JavaScript, Vue, C#/.NET, COBOL, or Go) from a public GitHub, GitLab, or Bitbucket repo, using a fast, simplified regex-based analyzer (not the full AST parser the real CLI tool uses for Python/Java/JavaScript — see the GitHub repo for the accurate version). AI explanations run on the top 3 riskiest files only, when an API key is configured. Bitbucket has no single "list all files" API, so that scan walks folders directly and may not reach every file in a very large or deeply nested repo — the scan result says so explicitly when that happens.

Private code, or hosted somewhere other than GitHub? Zip your codebase (up to 4.5MB) and select "Upload ZIP" above — nothing needs to be public. For anything larger, or for code that must never leave your network at all, the open-source CLI runs entirely on your own machine. Run it locally →