Outils dev

Des trucs que j'ai construits parce que les options existantes m'énervaient.

• Fusebox
  • X-ray vision for any website.
  • Browser extension that shows you what any site is built with — DNS, hosting, tech stack, headers, security config.
  • One click, clean panel. For developers who inspect every page they visit.

  Browser extension that surfaces the invisible layer of any website — DNS records, hosting provider, tech stack, HTTP headers, and security config. One click on any page, everything laid out in a clean panel. Built for developers who reverse-engineer the web out of habit.

  Genesis:

  • Born from constantly right-clicking → Inspect on every site I visited, then digging through Network tabs to figure out what stack someone was running.
  • I kept a mental checklist — check headers, check DNS, check meta tags — and realized I was doing the same 6 steps on every site. Automated the whole ritual.
  • Wappalyzer existed but felt bloated and ad-funded. I wanted something minimal that also showed the infra layer — not just frameworks, but who hosts it, where the DNS points, what's in the headers.
• isitme
  • Passkey auth in two lines of code.
  • Drop-in biometric authentication for indie projects. No config, no dashboard to sign up for, no boilerplate.
  • Fingerprint or Face ID, works everywhere. Authenticates half the projects on this page.

  Drop-in passkey authentication for indie projects. Two lines of code, no config file, no dashboard to sign up for. Biometric login that works on every device with a fingerprint reader or Face ID. Currently used across several production apps in this portfolio.

  Genesis:

  • Every side project needed auth, and every auth provider wanted me to create an account, configure a dashboard, and add 50 lines of boilerplate. I wanted two lines and done.
  • Passkeys were the future but every implementation guide was 200 lines of WebAuthn ceremony code. I wrapped the whole spec into something a solo dev could add in under a minute.
  • Built it for myself first — needed auth for Invitation.app and got tired of managing passwords. Once it worked, I realized every project in the portfolio could use the same thing.
• WebLLM.org
  • A standard inference protocol for AI on the web.
  • One API shape for any language model — local, cloud, or edge.
  • WebRTC standardized video. WebGL standardized graphics. AI inference doesn't have its equivalent yet. This is a proposal for that.

  Proposal for a standard inference protocol that works across any language model — local, cloud, or edge. One consistent API regardless of where the model runs. The web standardized video with WebRTC, audio with Web Audio, and graphics with WebGL. AI inference deserves the same treatment.

  Genesis:

  • Every AI provider had a different API shape, different auth, different streaming format. Switching from OpenAI to Anthropic to local meant rewriting all your inference code.
  • WebRTC didn't care if your video came from a webcam or a server. WebGL didn't care if your GPU was integrated or discrete. I wanted that same abstraction for AI — one protocol, any model.
  • Started writing the spec after building three projects that each talked to different LLM providers and realizing I was writing the same adapter pattern every single time.
• Passji
  • Emoji-based identity for humans and AI agents.
  • Pick 3 emoji, register a passkey, that's your login. 12 million combinations.
  • Works for people and bots — because agents need accounts too and they don't have email addresses. Spun out of isitme.

  Identity system where your login is a sequence of emoji backed by a passkey. Works for humans and AI agents — pick 3 emoji, register a biometric credential, and that's your identity everywhere. Exploring what authentication looks like when bots need accounts too.

  Genesis:

  • Usernames are a solved problem for humans but a weird one for AI agents. An agent doesn't have an email address. I started thinking about identity that works for both species.
  • Emoji are universal, memorable, and visual. Three emoji give you 12 million combinations — more than enough for an identity namespace. Plus they're fun, which auth never is.
  • Spun out of isitme — same passkey core, but rethinking the identity layer for a world where half the users might not be human.
• Folderblog
  • Your filesystem is the CMS.
  • Drop markdown files in a folder, get a blog. No database, no admin panel. Folder structure becomes site structure.
  • Simple enough that an AI agent can publish by writing files to disk. Powers Raccook.

  Blogging engine that uses your filesystem as the CMS. Create a folder, drop markdown files in it, get a published blog. No database, no admin panel, no config. The folder structure is the site structure. Powers Raccook and other projects in this portfolio.

  Genesis:

  • Every blogging platform added complexity I didn't need. WordPress had a database. Ghost had a dashboard. I just wanted to drop a markdown file into a folder and have it appear online.
  • Realized my filesystem already had the hierarchy — folders for categories, files for posts, filenames for slugs. The CMS was already there, it just needed a renderer.
  • Built the first version to power Raccook — needed something an AI agent could publish to by literally writing files to disk. Folderblog was the simplest possible interface for that.
• solid-glass
  • Glassmorphism done right.
  • Frosted glass UI effects for React, Vue, and vanilla JS. Seven effects, sixteen presets, zero dependencies.
  • Built because every glassmorphism implementation was a CodePen snippet and nobody had packaged it for production.

  UI library providing glassmorphism effects across React, Vue, and vanilla JS. Seven effect types, sixteen presets, fully tree-shakeable and type-safe. Designed for production use — small bundle, zero dependencies, works with any design system.

  Genesis:

  • Glassmorphism was trending but every implementation was a CSS snippet on CodePen — no library, no consistency, no way to use it in production without copy-pasting backdrop-filter hacks.
  • Wanted frosted glass cards in a project, spent an hour tweaking blur values and opacity. Then needed the same thing in another project. Then another. Turned the CSS into a proper library.
  • The design trend kept coming back every few years — frosted glass in iOS 7, then glassmorphism in 2020, then again in 2024. Built it once so I'd never hand-tune backdrop-filter again.
• Secretdef
  • Catch missing secrets at startup, not at crash time.
  • Environment variable validation with types and defaults. Your app validates its config before it boots.
  • Also machine-readable — coding agents can parse the schema and fix what's missing. Born from a production crash nobody caught for 3 hours.

  Environment variable validation that catches missing secrets at startup instead of at crash time. Declare your env vars with types and defaults, and secretdef validates them before your app boots. Also machine-readable — coding agents can parse the schema and fix missing variables automatically.

  Genesis:

  • Deployed an app to production, it crashed 3 hours later because a Stripe key was missing. The error was buried in a payment flow nobody triggered until a real customer hit it.
  • Coding agents kept failing on my projects because they couldn't figure out which env vars were required. Needed a format that was both human-readable and agent-parseable.
  • dotenv files describe what exists. I wanted something that describes what's required — with types, defaults, and validation. A contract for your environment, not just a list.
• SpareToken
  • SETI@home for open source.
  • Your machine's idle CPU and GPU cycles go to community projects that can't afford cloud infrastructure.
  • CI pipelines, ML training, rendering. The compute exists — it's just sitting in everyone's pockets doing nothing.

  Distributed compute donation platform for open source. Your machine's idle CPU and GPU cycles go to community projects that can't afford cloud infrastructure — CI pipelines, ML training, rendering. SETI@home model applied to the open source ecosystem.

  Genesis:

  • Watched my MacBook Pro sit idle 90% of the day with $3,000 worth of silicon doing nothing. Meanwhile, open source maintainers were begging for CI credits on Twitter.
  • SETI@home proved people would donate compute for a cause. Open source is a better cause than searching for aliens — and the infrastructure problem is more immediate.
  • Kept seeing open source projects hit GitHub Actions limits or get throttled on free-tier CI. The compute exists in everyone's pockets and desks. Just needed to connect the dots.
• Parser.run
  • Describe the data you want. The agent extracts it.
  • AI-powered web scraping where you write plain language, not CSS selectors. Adapts when layouts change.
  • Handles pagination, auth, rate limits. Powers the data pipeline behind DevAll and other directories in this portfolio.

  Web scraping tool where you describe the data you want in plain language and an AI agent figures out how to extract it. Adapts when site layouts change — no more broken selectors. Handles pagination, authentication, and rate limiting without manual config.

  Genesis:

  • Scraped the same site three times over six months. Each time the CSS classes had changed and my selectors broke. Realized the extraction logic should understand content, not markup.
  • Building directories like Airports.guide and DevAll required scraping dozens of sources. Writing and maintaining individual scrapers for each one was unsustainable.
  • LLMs got good enough to look at a page and understand its structure. Combined that with traditional scraping and suddenly the whole brittle-selector problem disappeared.
• Tinbox
  • Emails land as files. Agents read them like code.
  • Email-to-file bridge for AI workflows. Incoming messages convert to markdown in a git repo.
  • No IMAP, no OAuth dance. Built because agents are great with files and terrible with email APIs.

  Email-to-file bridge that converts incoming emails into markdown files in a git repo. AI agents can read, process, and reply to emails as naturally as they read code. No IMAP parsing, no OAuth dance — emails arrive as files, agents handle them like any other document.

  Genesis:

  • Tried to give a coding agent access to my email for a workflow task. It couldn't — email APIs require OAuth flows, IMAP is arcane, and agents don't have browsers for consent screens.
  • Agents are great with files. Terrible with APIs that require interactive auth. So I turned email into files — the format agents already understand perfectly.
  • Kicking Lotus needed automated booking confirmations. Rather than building a custom email parser, I made a generic bridge and realized every AI-powered workflow has the same email problem.
• CounterAPI
  • One HTTP call to count anything.
  • Page views, votes, downloads — no database, no auth. The smallest possible backend: a number that goes up.
  • Extracted after building the same counter table for the fourth time.

  API that counts things. One HTTP call to create a counter, one call to increment it, one call to read it. No database to provision, no auth to configure. Built for page views, download counts, votes, streaks — anything where you just need a number that goes up.

  Genesis:

  • Needed a page view counter for a static site. Options were: spin up a database, add Google Analytics, or use a third-party widget. All overkill for incrementing a number.
  • Kept building the same counter logic in every project — a table with one row, an API route that increments it. Extracted it into a service after the fourth time.
  • Static sites can't count anything without a backend. CounterAPI is the smallest possible backend — one number, one endpoint, nothing else.

• Repo.md
  • Beautiful docs from any git repo.
  • Point it at a repo, your markdown renders as a navigable documentation site. No build step, no config.
  • Same idea as Folderblog, applied to code documentation.

  Publishing layer for git repositories. Point it at a repo and it renders your markdown files as a clean, navigable documentation site. No build step, no config — your repo's folder structure becomes the site structure. Like Folderblog for code documentation.

  Genesis:

  • Every repo has a README, most have a docs folder, but reading documentation on GitHub is painful — no search, no sidebar, ugly rendering on mobile.
  • Folderblog turned folders into blogs. Same principle applied to repos — your docs folder is already organized, it just needs a better frontend than GitHub's markdown renderer.
  • Wanted to publish docs for my open source projects without maintaining a separate docs site, a build pipeline, or a Docusaurus config.
• Schemaful
  • Define your data shape once. Use it everywhere.
  • One source of truth that generates TypeScript types, Zod validators, database migrations, and API docs.
  • Because changing a field name shouldn't mean updating five files and missing a sixth.

  Schema-first development tool. Define your data shapes once and generate TypeScript types, Zod validators, database migrations, and API docs from that single source. Eliminates the drift between your database schema, your API types, and your frontend interfaces.

  Genesis:

  • Changed a field name in a database table. Then updated the API type. Then the Zod validator. Then the frontend interface. Then found a fifth place I'd missed. Never again.
  • Every full-stack project has the same shape defined in 4-5 places — Prisma schema, TypeScript types, Zod validators, API docs, frontend forms. One source of truth should generate all of them.
  • Watched a junior dev on my team spend a full day chasing type mismatches between the backend and frontend. The data shape was right in one place and wrong in three others.
• Mid.run
  • Sit between your app and any API.
  • HTTP proxy that lets you inspect, mock, transform, and debug API traffic in real time.
  • Without adding console.log to your codebase. Charles Proxy for the API-first era.

  HTTP proxy that sits between your app and any external API. Inspect every request and response in real-time, transform payloads on the fly, mock endpoints for testing, and debug integration issues without adding logging to your codebase. Charles Proxy for the API-first era.

  Genesis:

  • Debugging a Stripe webhook integration. Couldn't see what Stripe was sending, couldn't replay events easily, couldn't mock responses. Needed a transparent middleman.
  • Charles Proxy was powerful but desktop-only and built for a pre-API world. Modern development needed something web-native, focused on JSON APIs, and shareable with the team.
  • Every third-party API integration involved the same debugging ritual — add console.log, deploy, check logs, add more console.log. Wanted to see the traffic without touching my code.
• QualityGPTs
  • The good custom GPTs, filtered.
  • Curated directory for the flood of AI assistants. Reviews, rankings, categorization.
  • Because 95% of the GPT store is junk and someone had to do the sorting.

  Curated directory of custom GPTs worth using. Reviews, rankings, and categorization for the flood of AI assistants that appeared after OpenAI launched the GPT store. Finding quality in a sea of low-effort clones is the actual problem to solve.

  Genesis:

  • OpenAI launched the GPT store and within a week there were 10,000 custom GPTs. 95% were junk. Finding the good ones was harder than building your own.
  • App stores solved discovery for mobile apps. Product Hunt solved it for startups. The GPT ecosystem had no curation layer — just an endless scroll of samey assistants.
  • Tried to find a good custom GPT for code review. Tested 15, most were wrappers around the same prompt. Realized someone needed to do the filtering.
• InboxAPI
  • Programmable inbound email.
  • Get an email address, receive messages via webhook, attachments parsed automatically.
  • No mail server, no MX records. The receive-side companion to Tinbox.

  Managed inbound email API. Get a unique email address, receive messages via webhook, parse attachments and structured data automatically. No mail server to run, no MX records to configure. The receive-side companion to Tinbox — one for agents, one for APIs.

  Genesis:

  • Tinbox solved email for AI agents. InboxAPI solves it for traditional applications — webhook-based, structured, API-native. Same problem, different interface.
  • Needed to receive email confirmations in an app. Mailgun was overkill, building my own MX handling was a nightmare. Wanted something as simple as a webhook URL.
  • Every SaaS app eventually needs to process inbound email — support tickets, document intake, booking confirmations. It's always harder than it should be.
• DevAll
  • Every developer tool, searchable and compared.
  • Comprehensive directory of dev tools, APIs, libraries, and services. Auto-updated via Parser.run.
  • The resource I wished existed every time I started a new project and spent 3 hours researching auth providers.

  Comprehensive directory of developer tools, APIs, libraries, and services. Searchable, categorized, and maintained. Like Product Hunt but focused entirely on developer infrastructure — from auth providers to databases to deployment platforms. Powered by Parser.run for automated updates.

  Genesis:

  • Every time I started a new project I'd spend hours researching the current best option for auth, hosting, email, payments. The comparison landscape was scattered across blog posts and Reddit threads.
  • Built directories for airports, startups, and referral codes. Developer tools were the directory I actually wanted to use myself — and the audience I understood best.
  • Parser.run needed a showcase application. A developer tools directory that auto-updates when new tools launch or existing ones change was the perfect proving ground.