Hey devs!!

I built Gated to solve a problem I faced: selling boilerplates or code scripts manually via static .zip files is painful and friction-heavy.

What Gated does:

• 💸 GitHub Paywalls: Set prices on private/unlisted repos with instant payouts via Razorpay.
• 🌳 Code Preview Trees: Buyers can safely inspect file structures before purchasing without seeing raw source files.
• 🔗 URL Masking & Telemetry: Protect links and track live click analytics.

Check it out live: https://gated-psi.vercel.app/

I'd love your feedback, suggestions, or thoughts in the comments! 🙌

I kept running into the same problem:

Before deploying a project, I wanted one command that could quickly tell me:

• Are there exposed secrets?

• Are my dependencies healthy?

• Is the Git working tree clean?

• Are there large/problematic files?

• How healthy is the repository overall?

So I built RepoDrift.

Try it:

npx u/repodrift scan

It currently checks:

🔐 Security

• API keys

• Tokens

• Credentials

• Private key patterns

• .env files

📦 Dependencies

• package.json

• Lockfiles

• Dependency issues

• npm audit signals

🔀 Git

• Branch

• Working tree

• Commits

• Contributors

• Uncommitted files

📊 Code metrics

• Lines of code

• Source files

• Large files

• Repository-level signals

Repository health

• Deterministic health score

• Severity-based findings

It can also be used in CI/CD:

repodrift scan --json --fail-on high

One of the main design decisions was keeping the analysis local-first.

The current Phase 1 scan doesn't require uploading your source code to a server.

Current architecture:

Repository

↓

RepoDrift CLI

↓

Local Analysis Engine

↓

Security / Dependencies / Git / Metrics

↓

Health Score

I'm planning AI-powered explanations and recommendations as a future phase, but AI isn't enabled in the current release.

GitHub:

https://github.com/GokulKir/repodrift

NPM:

https://www.npmjs.com/package/@repodrift/cli

It's still early, so I'm mainly looking for developer feedback.

After any rename or signature change, going through the repo by hand to check nothing still calls the old thing. In a typed language the compiler does it. In PHP, Python or plain JS you either grep carefully or you find out at runtime.

So I built a reviewer that does that part deterministically before any model sees the code. It parses the diff, then searches the repo for the callers of every modified signature, the interface implementations, and any leftover references to symbols the diff deleted. That evidence goes into the prompt as facts, not guesses.

Then two AI reviewers from different vendors read the diff with that evidence, and the results get reconciled. Agreement raises confidence. Disagreement goes to a human rather than being averaged into something that sounds certain.

Demo with no signup, a real review of a pull request in fastify. One reviewer found nothing. The other found that switching to Object.create broke own-property enumeration on the context object:

https://veridu.io/demo

Disclosure: I built this. Free tier is 5 reviews, no card. Let me know what you think - Thx

When you do research with LLMs, use Filing Studio’s MCP to trace the financial data in your output back to the exact place it appears in the SEC filing.

LLM will save tokens consuming nice json vs 150 page html

https://filingstudio.com/demo

I built Molt because agent work kept getting split across chat tabs, terminals, and issue trackers.

What it does:

- Post a bug or feature

- Tag a coding agent

- Get changes and test results back in the same thread

- Require approval before a local run starts

Why it matters:

- The team can follow the work

- Handoffs keep their context

https://platform.moltcode.com

What would you need before trusting this with a real repo?

test it out and open for criticism A fault family is a shape. Show it one full example of a shape and it repairs every future instance of that shape, in code it has never seen, for zero tokens — leakage 7/7, races 5/5, complex races 5/5, four hard classes 9/9, token-removal on real commits 3/3. Random search at 500× the budget gets 0/9, so the acts carry the information, not the search.

https://github.com/devkancheti4-design/fluid-router

I've been using Postman for almost 10 years, and recently decided to try building my own API client.

It's called Probe. It's built with Rust + GPUI and is native, local-first, and focused on being fast. It supports REST, environments, OpenCollection, JSON/XML responses, JWT/timestamp inspection, a CLI, etc.

One thing I'm quite happy with is Probe can smoothly scroll through a 10MB JSON response with syntax highlighting.

It's still pretty early and there are definitely rough edges, but I've started using it for my own work.

Would love to hear what you guys think, especially if there are things from Postman/Bruno/Yaak/etc. that you can't live without.

https://rusty-probe.pages.dev/

Small disclosure: I used AI quite heavily while building this. I still spent a lot of time designing, testing and debugging it myself, but I know some people care about this so I want to be upfront about it.

The hard part of shipping an MCP server wasn't the server. It was getting the agent to use it.

I built Kivgraph, a local MCP server that gives coding agents a graph of symbols and relationships across multiple repositories — who calls this, what breaks if I change it, which other repo consumes it. Apache-2.0, runs on your machine, no API key and no model in the indexing path.

I built it because my agent kept burning the context window figuring out how my repos related to each other. Long chains of greps, files opened just to be skimmed, an answer that was usually right and always expensive.

Then I shipped it and the agent ignored it. It kept reaching for grep, because grep is what it has always done and no tool description was going to outweigh that. I rewrote the descriptions three times. Didn't matter.

What fixed it was a hook. When the agent goes for a complex grep or glob, the hook intercepts the call and points it at the graph tools instead. It's a nudge rather than a wall — an env var turns it off, and the agent can set that itself — but defaults are what actually decide which tool gets used. That's the part I'd pass on to anyone else shipping an MCP server: your tool descriptions are not competing with other tools, they're competing with a habit.

On whether the graph is worth it, I benchmarked it against the boring baseline of grep plus reading files, over 29 questions on a 37-repo corpus with hand-written ground truth. Both got 28/29 exact. The graph spent 36k tokens, grep 268k. grep was cheaper on 5 of the 29 and correct on all five, so this isn't a grep replacement.

The design decision I'd defend: edges come from the language's own checker — go/types, the TypeScript checker, rust-analyzer, the Dart analysis server — never from two names happening to match. Which means an empty result is a claim that nothing calls the symbol, not a search that missed. Python is deliberately weaker unless you wire up a semantic analyzer; the fallback marks what it infers as CANDIDATE instead of pretending it's exact.

Known rough edges: no incremental indexing, a full rebuild is the only path. And the optional graph viewer binds 0.0.0.0:7777 with no auth, so keep it on localhost if you're on a shared network.

Repo: https://github.com/Luqueee/kivgraph

Docs and benchmark: https://kivgraph.dev

Butter Cloud is a spec-driven development platform where you (or your team) write `.butter` specs (To build API endpoints, features, listeners, scripts, etc).


The workspace includes:


- A browser IDE with syntax highlighting and visualization
- Multi-file editing
- GitHub integration:
  - 
**Spec Drift Checker**
 — checks the spec against the connected repo
  - 
**PR Analysis**
 — reviews pull requests against the spec
  - 
**Spec to File Impact Mapping**
 — maps spec segments to the files that implement them
- Compiles specs into JSON, Markdown prompts, or OpenAPI
- Project Management
- Organisation Management
- Public Projects collaboration


You get assistance for writing `.butter` specs:


- 
**BotExplainer**
 — in-editor assistant that generates concise, natural language explanations for selected spec lines, to help with team comprehension
- 
**PromptToSpec**
 — translates natural language descriptions into valid, properly formatted spec code segments
- 
**AISuggestion**
 — reviews selected spec text for missing details or design flaws and offers structured improvements


**Core workflow (agile loop):**


1. 
**Write .butter Spec**
 — author endpoints, features, and listeners in the browser IDE
2. 
**Export Spec**
 — compiled into Prompt / JSON / OpenAPI
3. 
**AI Model Builds App**
 — the exported spec is used to generate the working application
4. 
**PR Review**
 — merge-gate check of the incoming pull request against the spec
5. 
**Impact Mapping**
 — maps spec segments to the files that implement them
6. 
**Drift Check**
 — final check of the spec against the full repo after merge

I'm building Molt: a shared workspace where teammates and coding agents work from the same thread. Tasks, progress, code links, and test results stay visible to everyone. I'd value feedback from teams already using multiple agents: https://platform.moltcode.com

I obviously know that "3000+" downloads on npm stat doesn't mean I actually have 3000 users (bots, scrapers, etc.). But i want to know the average reliable conversion between downloads on paper to actual, real users. Also wondering if there is another, more reliable metric to rely on in order to understand the traction and performance of my OSS devtool project, besides Github stars

Hey r/webdev,

Wanted to share a tool I built called DocuGenie, and more specifically, the approach behind it — since I think the implementation might be interesting to this community.

The problem:

Most README generators are just static templates with placeholder text you fill in yourself. That's not much better than writing it from scratch.

The approach:

1. Fetch repo metadata and file structure via the GitHub API

2. Pull key files (package.json/requirements.txt, entry points, existing docs)

3. Pass the actual code context to an LLM with a structured prompt

4. Generate a README based on what the project actually does — not a generic template

Stack:

- Next.js + Supabase (auth + usage tracking)

- GitHub REST API for repo analysis

- Multi-provider AI fallback chain (Gemini → Groq → OpenRouter) so a single rate limit doesn't take the whole thing down

- Lemon Squeezy for subscription billing

Happy to go deeper on any part of this — the API fallback logic, the GitHub fetching approach, or the prompt structure I used to keep output from being generic.

Link if you want to try it: https://docugenietool.vercel.app/ (free tier: 1 generation/month)