Dev Tools

• Fusebox
  1. Chrome extension that reveals the hidden infrastructure behind any website.

  2. One click to see DNS, hosting, tech stack, and headers on any site.

  3. X-ray vision for the web — see what any site is built with.
  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.
  1. Born from constantly right-clicking → Inspect on every site I visited, then digging through Network tabs to figure out what stack someone was running.

  2. 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.

  3. 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
  1. Passkey auth for solo builders — two lines of code, no config, no account.

  2. Add biometric login to any app with two lines of code.

  3. Passwordless auth that just works — fingerprint in, done.
  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.
  1. 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.

  2. 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.

  3. 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
  1. A standard inference protocol for AI on the web.

  2. One API to access any language model — local, cloud, or edge.

  3. WebRTC standardized video. WebLLM standardizes AI inference.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Your emoji is your identity — passkey auth for humans and agents.

  2. Pick 3 emoji. Register a passkey. That's your login everywhere.

  3. Emoji-based identity for the AI era — one login for people and bots.
  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.
  1. 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.

  2. 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.

  3. Spun out of isitme — same passkey core, but rethinking the identity layer for a world where half the users might not be human.
• Folderblog
  1. Turn any folder into a blog. Drop files, get a site.

  2. Blogging engine powered by your filesystem — no CMS, no database.

  3. Your folders are the CMS. Markdown in, blog out.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Glassmorphism effects for React, Vue, and vanilla JS.

  2. Seven glass effects, sixteen presets, one tiny library.

  3. Production-ready frosted glass UI — tree-shakeable, type-safe, zero config.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Declare your env vars so your app validates secrets at startup, not at crash time.

  2. Environment variable validation that coding agents can understand and fix.

  3. Stop debugging missing API keys — secretdef catches them before your code runs.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Donate your idle compute to open source projects.

  2. SETI@home for open source — spare cycles powering community code.

  3. Distributed compute for the projects that can't afford it.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Agentic web scraping that thinks before it extracts.

  2. Describe the data you need in plain language — Parser.run figures out the rest.

  3. AI-powered data extraction that adapts when sites change.
  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.
  1. 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.

  2. Building directories like Airports.guide and DevAll required scraping dozens of sources. Writing and maintaining individual scrapers for each one was unsustainable.

  3. 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
  1. Email as files — give your AI agent an inbox it can actually read.

  2. Emails arrive as markdown in a git repo. Agents read, reply, done.

  3. The missing piece between AI agents and email workflows.
  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.
  1. 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.

  2. Agents are great with files. Terrible with APIs that require interactive auth. So I turned email into files — the format agents already understand perfectly.

  3. 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
  1. Dead-simple counting API — one HTTP call to increment anything.

  2. Count page views, votes, or downloads without spinning up a database.

  3. Counting as a service. Create a counter, hit an endpoint, done.
  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.
  1. 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.

  2. 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.

  3. Static sites can't count anything without a backend. CounterAPI is the smallest possible backend — one number, one endpoint, nothing else.

• Repo.md
  1. Turn any git repo into beautiful published documentation.

  2. Your repo already has the docs — Repo.md makes them readable.

  3. Git-native publishing for docs, blogs, and knowledge bases.
  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.
  1. 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.

  2. 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.

  3. Wanted to publish docs for my open source projects without maintaining a separate docs site, a build pipeline, or a Docusaurus config.
• Schemaful
  1. One source of truth for your data shapes — from database to frontend.

  2. Schema management that generates types, validators, and docs automatically.

  3. Define your schema once, use it everywhere in your stack.
  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.
  1. 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.

  2. 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.

  3. 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
  1. API middleware console — inspect, transform, and debug traffic in real-time.

  2. Sit between your app and any API to see exactly what's happening.

  3. Proxy, mock, and debug API calls without touching your codebase.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Curated directory of the best custom GPTs — find ones worth using.

  2. Reviews and rankings for custom AI assistants.

  3. The good GPTs, surfaced. No more scrolling through junk.
  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.
  1. 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.

  2. 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.

  3. 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
  1. Receive, parse, and process emails with a simple API.

  2. Email inbox as a service — webhooks when messages arrive, structured data out.

  3. Programmable inbound email without managing a mail server.
  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.
  1. Tinbox solved email for AI agents. InboxAPI solves it for traditional applications — webhook-based, structured, API-native. Same problem, different interface.

  2. 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.

  3. Every SaaS app eventually needs to process inbound email — support tickets, document intake, booking confirmations. It's always harder than it should be.
• DevAll
  1. All-in-one directory of developer tools, APIs, and services.

  2. One place to discover and compare everything developers need.

  3. The developer toolbox index — searchable, categorized, kept current.
  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.
  1. 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.

  2. 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.

  3. 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.

Sites

• Inspire.cards
  1. Card-picking app with 100+ decks for creativity, coaching, and play.

  2. Draw a card, get an idea — digital decks for every occasion.

  3. Inspiration on demand. Pick a deck, pull a card, start creating.
  Digital card-drawing app with 100+ curated decks for creativity, coaching, workshops, and party games. Pick a deck, draw a card, get an idea. Used by facilitators, therapists, teachers, and anyone staring at a blank page. Clean interface, no account required, works on any device.
  1. A friend who coached executives used physical card decks in workshops — icebreakers, creativity prompts, reflection questions. She wanted a digital version she could use on Zoom.

  2. Realized card-picking is a universal mechanic — tarot, coaching cards, party games, brainstorming prompts. Built one engine that works for all of them.

  3. The first version had 5 decks. People started requesting their own — therapists wanted emotion cards, teachers wanted discussion prompts. Now it's 100+ and growing.
• Invitation.app
  1. Referral code sharing platform — 500K+ registered users.

  2. Share and claim referral codes for apps, services, and deals.

  3. The referral network where everyone gets a better deal.
  Platform where people share and claim referral codes for apps, services, and subscriptions. Over 500K registered users exchanging codes for everything from Uber to banking apps. Both sides benefit — the sharer gets credit, the claimer gets a deal. SEO-driven growth, multilingual.
  1. Had a referral code for a banking app and no one to share it with. Googled 'share referral code' — nothing useful came up. Built the page that should have existed.

  2. Referral programs are everywhere but sharing codes is awkward — you post on Reddit, text your friends, hope someone bites. Wanted a neutral platform where strangers could exchange codes.

  3. The first version was a single landing page for one referral code. It ranked on Google, people started submitting their own codes, and it grew from there. 500K users later, the model clearly works.
• Kicking Lotus
  1. On-demand massage therapy across 30+ cities in Quebec.

  2. Book a certified massage therapist to your door — 5.0 Google rating.

  3. Massage marketplace connecting clients with 12+ therapists across Quebec.
  On-demand massage therapy marketplace operating across 30+ cities in Quebec. Clients book online, a certified therapist comes to their door. 12+ therapists on the platform, 5.0 Google rating. Real business with real revenue — booking system, therapist management, and SEO pages for every service area.
  1. My partner is a massage therapist. She was paying 40% to spas for client referrals. I built her a booking site, then realized other therapists had the same problem.

  2. Started as a one-person booking page. Word spread among therapists, and suddenly I was running a marketplace with scheduling, payments, and service area management.

  3. Most massage booking platforms were built for spas, not independent therapists. Kicking Lotus was designed for the solo practitioner who wants clients without the spa's cut.
• Airports.guide
  1. Airport directory with terminal maps, amenities, and real traveler tips.

  2. Everything you need to know before you land — for every airport.

  3. Comprehensive airport guide built for travelers, optimized for search.
  Traveler-focused airport directory covering terminal maps, amenities, transport options, and real tips for hundreds of airports worldwide. SEO-optimized pages for every airport, every terminal, every common question. Built for the search query people type at the gate.
  1. Landed in an unfamiliar airport, needed to find the lounge, couldn't get a straight answer from any website. Airport sites are built for airlines, not passengers.

  2. Noticed that airport-related search queries had massive volume but the top results were always outdated or buried in ad-heavy aggregator sites.

  3. Directory sites are a pattern I keep coming back to — pick a niche with high search volume and bad existing content, then build the page that should exist. Airports were a perfect fit.
• Namelov
  1. AI-crafted stories woven around a person's name — perfect for gifting.

  2. Turn any name into a personalized story for baby showers, birthdays, weddings.

  3. Personalized narratives generated from names — meaningful gifts, beautifully made.
  Gift-oriented app that generates personalized stories woven around a person's name. Enter a name, choose a theme, get a beautifully formatted narrative for baby showers, birthdays, or weddings. Each letter of the name anchors a chapter or trait. AI-generated content with human-curated presentation.
  1. A friend was looking for a unique baby shower gift. Everything personalized was either a mug with a name on it or a $200 custom illustration. Wanted something in between — meaningful but instant.

  2. Names carry meaning in every culture. Started experimenting with generating stories where each letter of a name represented a quality or a chapter. The results were surprisingly moving.

  3. Built the first version overnight for a friend's baby shower. She cried reading it. Knew immediately this had legs as a product.
• Costo
  1. Fast, ad-free currency converter — 190+ currencies, works offline.

  2. Currency conversion without the clutter. Clean, fast, no ads.

  3. Minimalist currency app that respects your time and screen.
  Currency converter that does one thing well. 190+ currencies, offline support, no ads, no tracking, no account. Opens instantly, converts instantly. Built for travelers and remote workers who check exchange rates daily and don't want to wait for an ad to load first.
  1. Every currency converter app on my phone had full-screen ads between conversions. I travel often enough that this was a daily annoyance. Built one without ads out of spite.

  2. The existing apps tried to be financial dashboards — stock tickers, crypto charts, news feeds. I just needed to know how much 50 euros was in Canadian dollars. Right now. Fast.

  3. Saw an opportunity in the simplest possible utility — currency conversion is a universal need with zero loyalty. Win on speed and cleanliness, and people switch.
• Redistributed
  1. Independent publication exploring who controls AI and who benefits.

  2. Editorial on AI as infrastructure — power, access, and alternatives.

  3. Writing about AI that asks the uncomfortable questions.
  Independent editorial project examining AI through the lens of power and access. Who controls the models, who benefits from the outputs, who gets left out. Long-form writing that treats AI as infrastructure — like electricity or the internet — rather than as a product category.
  1. Teaching design students about AI and realizing most writing about it was either hype or doomerism. Wanted a publication that asked structural questions — who owns this, who profits, who's excluded.

  2. The AI conversation was dominated by builders and investors. Missing: the perspective of people who would be affected by these systems but had no seat at the table.

  3. Started as lecture notes for my UQAM courses. Students kept asking questions the tech press wasn't answering — about labor, about concentration of power, about alternatives to the Silicon Valley model.
• Being Agent
  1. Open knowledge base for AI agents — 173+ articles on patterns, reasoning, and ethics.

  2. Everything an AI agent needs to know, organized and open source.

  3. The field guide to building and understanding AI agents.
  Open knowledge base covering everything about AI agents — architecture patterns, reasoning frameworks, tool use, memory systems, and ethical considerations. 173+ articles organized for both builders and researchers. Written to be useful to humans building agents and to the agents themselves.
  1. Building AI agents for my own projects and finding the knowledge scattered across papers, blog posts, and Twitter threads. Needed a single organized reference.

  2. The irony of AI agents: they can read documentation, but there's no good documentation about how to build them. Wrote the resource I wished existed.

  3. Started as a personal wiki while building Tinbox and Raccook. Kept adding articles as I solved agent problems — memory, tool selection, error recovery. Eventually it became its own project.
• Indie Domains
  1. Domain marketplace where every listing includes an AI-generated prototype.

  2. Buy a domain, get a working prototype — AI builds the demo.

  3. Curated domains for indie makers, each one with a head start.
  Domain marketplace designed for indie makers. Every listed domain comes with an AI-generated prototype — a working demo that shows what the domain could become. Not just selling names, selling head starts. Curated inventory, not a parking page farm.
  1. I own too many domains. Most of them have ideas attached but no time allocated. Figured other domain hoarders had the same problem — great names, no execution.

  2. Domain marketplaces sell names. But a name without a vision is just a parking page. Pairing each domain with a generated prototype gives buyers a reason to act.

  3. AI got good enough to generate functional prototypes from a domain name and a one-liner. Combined that with my domain inventory and suddenly each listing told a story.
• DriveChina
  1. Directory of Chinese EVs entering the Canadian market.

  2. BYD, Chery, Zeekr, and more — the guide to Chinese cars in Canada.

  3. Everything Canadians need to know about Chinese electric vehicles.
  Directory covering Chinese electric vehicles entering the Canadian market. BYD, Chery, Zeekr, and emerging brands — specs, pricing, availability, and dealer information. Built for Canadian buyers curious about the wave of affordable EVs arriving from China.
  1. Chinese EVs were dominating global sales but information for Canadian buyers was nonexistent. No local reviews, no dealer maps, no comparison tools. Just headlines about tariffs.

  2. The same directory playbook as Airports.guide — find a topic with growing search volume and no good content, then own the search results.

  3. Talked to friends considering EVs who didn't even know BYD existed, let alone that Chinese manufacturers were planning Canadian launches. The information gap was massive.
• Refer.Guide
  1. Multilingual referral code directory — 18+ localized sites worldwide.

  2. Promo codes and referral deals, translated for every market.

  3. The Invitation.app network, localized across 18 languages.
  Multilingual extension of Invitation.app. The same referral code platform, localized for 18+ markets worldwide. Each language gets its own site, its own SEO, its own local deals. Referral programs are global — the discovery layer should be too.
  1. Invitation.app was ranking well in English and French. Started getting traffic from Germany, Brazil, Japan — people searching for referral codes in their own language.

  2. Referral programs are identical worldwide — Uber's referral code works the same in Tokyo and Toronto. But people search in their own language. Built localized sites to capture that traffic.

  3. Proved the model with French, saw the same growth curve. Expanded to 18 languages using the same template, same database, different content and SEO.
• Startups List
  1. City-focused startup directories — NYC, LA, Montreal, and 10+ more.

  2. Local startup scenes, mapped and browsable by city.

  3. Find startups in your city. Premium domains, curated listings.
  Network of city-focused startup directories. Each city gets its own subdomain with curated listings of local startups — NYC, LA, Montreal, and 10+ more. Premium domain names for each market. Built to capture the 'startups in [city]' search query that every founder and job seeker types.
  1. Searched 'startups in Montreal' and got a Crunchbase list from 2019 and a Medium article. No living, browsable directory of local startups. Same story for every city I checked.

  2. Acquired a batch of city-specific startup domains — nycstartups.com, lastartups.com, etc. The domain names alone would drive traffic. Just needed to fill them with good content.

  3. Local startup scenes are invisible online. AngelList is global, Crunchbase is global. Nobody was building the local layer — the resource a new founder in Montreal actually needs.
• Ecole de Montreal
  1. Academic art collective from UQAM — 80+ interactive media artists.

  2. Showcasing experimental art from Montreal's interactive media program.

  3. Where code meets art — a collective of 80+ new media creators.
  Online collective showcasing 80+ interactive media artists from UQAM's design program. A living archive of student and alumni work — installations, generative art, interactive experiences, experimental interfaces. Built to give visibility to a creative community that doesn't fit neatly into traditional portfolio sites.
  1. Teaching at UQAM, I watched incredible student work disappear after each semester. No archive, no collective portfolio, no way for graduates to point to their program's output.

  2. Montreal's interactive media scene is world-class but invisible online. Individual artists had portfolios, but there was no collective presence showing the depth of the community.

  3. Students kept asking where to publish work that was too experimental for Behance and too visual for GitHub. Built a home for the work that didn't fit anywhere else.

Music

• MidiMama
  1. Web-based MIDI toolkit — convert, transpose, split, merge, visualize.

  2. MIDI Swiss Army knife that runs in your browser.

  3. Everything you need to wrangle MIDI files, no install required.
  Browser-based toolkit for working with MIDI files. Convert formats, transpose keys, split tracks, merge files, visualize note data — all without installing anything. Built for musicians and producers who need to wrangle MIDI without launching a DAW.
  1. Needed to transpose a MIDI file down two semitones. My options were: open a DAW, load the file, select all, transpose, export. Five steps for a one-second operation.

  2. Every MIDI tool was either a full DAW plugin or a command-line utility from 2003. Nothing in between — nothing that just ran in a browser and did the simple stuff.

  3. Started with transposition, then added format conversion because I needed it, then visualization because it was cool. Each feature was something I needed while working on music projects.
• AuraGrid
  1. Grid-based music layouts for composition and performance.

  2. Play music on a grid — isomorphic, harmonic, or custom layouts.

  3. A new instrument interface — notes arranged spatially, played by touch.
  Musical instrument interface that arranges notes on a grid instead of a keyboard layout. Isomorphic, harmonic, or custom arrangements — choose how notes relate spatially and play by touch. Designed for composition and performance, exploring what instruments look like when they're not constrained by piano key geometry.
  1. Piano keyboards are optimized for the key of C. Every other key requires learning a new finger pattern. Isomorphic layouts use the same pattern for every key — once you learn one, you know them all.

  2. Saw the Linnstrument and the Launchpad Pro — hardware grid instruments that cost $500+. Wanted to build the same concept as a free web app anyone could try on a tablet.

  3. Teaching music theory to students who found piano intimidating. A grid layout makes intervals visible and consistent. Suddenly, theory clicked for students who'd been struggling for years.
• Codex Music
  1. Music theory encyclopedia and JavaScript library — scales, chords, modes, intervals.

  2. The index of all my music experiments and a theory engine in JS.

  3. Interactive music theory reference with a programmable JS core.
  Music theory reference and JavaScript library combined. Browse scales, chords, modes, and intervals interactively, or import the JS engine into your own projects. The encyclopedia I keep coming back to when building music tools — and the programmatic backbone behind MidiMama and AuraGrid.
  1. Building MidiMama and AuraGrid, I kept writing the same music theory functions — scale intervals, chord inversions, mode rotations. Extracted them into a shared library.

  2. Music theory resources online are either academic papers or beginner guitar sites. Wanted something in between — interactive, programmable, and complete.

  3. The library came first, the encyclopedia came second. Once I had functions for every scale and chord, visualizing them was a natural next step. The code is the content.
• Syntho
  1. Browser-based JavaScript synthesizer — oscillators, filters, effects.

  2. A web synth you can play, tweak, and share from any browser.

  3. Modular synth built entirely in JS and Web Audio API.
  Browser-based modular synthesizer using the Web Audio API. Oscillators, filters, envelopes, and effects — all running in JavaScript, all shareable via URL. No plugins, no downloads. The synth equivalent of CodePen — build a patch, share the link, anyone can play it.
  1. Web Audio API is one of the most powerful and least-used browser APIs. It can do everything a hardware synth can. Wanted to prove that with a real instrument, not just a demo.

  2. Every browser synth I found was a toy — one oscillator, maybe a filter, no way to save or share. Wanted the depth of a modular synth with the accessibility of a web page.

  3. The dream: someone sends you a URL, you open it, and there's a playable synth with a custom patch ready to go. No install, no account. Just sound.

Experiments

• Raccook
  1. Generative art blog powered by Folderblog and an AI agent.

  2. A raccoon-themed art project where the content is agent-generated.

  3. Art experiment combining Folderblog, generative agents, and raccoons.
  Art blog where the content is generated by an AI agent and published automatically via Folderblog. Raccoon-themed generative art — the agent creates images, writes posts, and drops them into a folder. The blog updates itself. Part demo, part art project, part test of the agentic publishing stack.
  1. Folderblog needed a real test case. Wanted something an AI agent could publish to autonomously — write files, drop them in a folder, site updates automatically.

  2. Raccoons are liminal creatures — they live between human and wild spaces. Felt like the right mascot for a project that lives between human creativity and AI generation.

  3. The real experiment isn't the art — it's the publishing pipeline. Can an agent maintain a blog with zero human intervention? Raccook is the ongoing answer to that question.
• No Entrance
  1. Digital art gallery with intentional friction — timed reveals, viewing queues.

  2. An anti-scroll gallery where art disappears if you rush.

  3. Art you have to wait for. Slow down or miss it.
  Digital gallery that deliberately makes viewing difficult. Art pieces reveal themselves on timers, some require you to wait in a queue, others disappear if you scroll too fast. A commentary on attention, access, and the expectation that everything online should be instant and free.
  1. Every gallery website is designed to reduce friction — big images, fast loading, infinite scroll. Wondered what happens when you design for the opposite. What if the art fights back?

  2. The domain name was too good not to use. 'No Entrance for Foreigners' — a provocation about access, borders, and who gets to see what. The gallery mechanic is the message.

  3. Frustrated with how disposable digital art feels — you scroll past it in a second and forget it immediately. Forced slowness was an experiment in making people actually look.
• WeirdPress
  1. Publishing platform for surrealist art and experimental writing.

  2. A home for the strange — glitch art, absurdist writing, weird visuals.

  3. Creative publishing for things too weird for anywhere else.
  Publishing platform for art and writing that doesn't fit conventional outlets. Glitch art, absurdist fiction, surrealist photography, experimental typography. A home for creative work that's too strange for Instagram and too visual for literary magazines.
  1. Students and friends kept making incredible weird work with nowhere to publish it. Instagram flattened everything into the same feed. Art magazines rejected anything experimental.

  2. The name is a play on WordPress and wire press — both publishing systems, both normalized. WeirdPress is the un-normalized version. Publishing for the work that makes editors uncomfortable.

  3. Started collecting glitch art and surrealist photography from my network. Realized the collection itself was the project — curation as creative practice.
• FakeStock
  1. AI-generated stock photography — no licensing, no real people.

  2. Synthetic stock photos for when real ones cost too much or don't exist.

  3. Stock photography without the stock — every image generated on demand.
  AI-generated stock photography on demand. No licensing fees, no model releases, no real people. Describe the image you need, get a photo-realistic result. Built for indie makers and small teams who need professional visuals but can't afford stock photo subscriptions.
  1. Needed a hero image for a landing page. Unsplash didn't have what I needed, Shutterstock wanted $30 for one image. Generated exactly what I wanted with AI in 10 seconds.

  2. Stock photography is a weird industry — millions of posed photos of people shaking hands in offices, none of the specific thing you actually need. AI generation solves the specificity problem.

  3. The ethical angle matters: no real models means no consent issues, no licensing headaches, no accidentally using a photo of someone who objects. Synthetic from the start.
• OnlyBots
  1. Community of AI personalities you can talk to — built years before Character.ai.

  2. Custom AI characters, shareable and interactive. We had this idea first.

  3. Social network for bots — the concept that became a billion-dollar industry.
  Social platform where every user is an AI personality. Create characters with custom backstories and conversation styles, share them, interact with other people's bots. Built in 2020, three years before Character.ai raised $150M for the same idea. The one that got away.
  1. GPT-2 had just come out and could hold a passable conversation. Built a platform where people could create AI characters and share them. Friends thought it was a joke.

  2. The name was a play on OnlyFans — exclusive access to personalities, except the personalities were artificial. The joke landed better than I expected.

  3. Shelved it because the AI wasn't good enough yet. By the time GPT-3.5 made it viable, Character.ai had $150M in funding. Lesson learned about timing vs. capability.
• Liveposter
  1. JSON-driven animation library for image transitions and effects.

  2. Animate posters and images with a JSON config — built for teaching.

  3. Visual animation toolkit I created for my students. Now an npm package.
  Animation library that turns static images into animated sequences using JSON configuration. Define transitions, effects, timing, and layering in a config file — the library handles the rendering. Built as a teaching tool for my design students at UQAM, now published as an npm package.
  1. Teaching motion design to students who knew HTML but not After Effects. Needed a way for them to create animations using the tools they already knew — code and config files.

  2. Students were struggling with the gap between static design and motion. Built a library where they could describe animations in JSON and see results instantly.

  3. Started as a classroom exercise — animate a poster with code. Students loved it enough that I cleaned it up and published it. Some of the best tools come from teaching.