In their book Getting Real, 37signals talk about Open Doors — the idea that you should give customers access to their data through RSS feeds and APIs. Let them get their information when they want it, how they want it. Open up and good things happen.

Fizzy takes that seriously. When 37signals released Fizzy with its full git history available, they didn’t just open-source the code — they shipped a complete API and webhook system too. The doors were wide open baby!

So I dove in — reading the source, building tools, and sharing what I found. Every time curiosity kicked in, there was a direct path from “I wonder if…” to something I could actually try and execute. This post is a catch-all for my very bubbly month of December.

Writing

Fizzy Webhooks: What You Need to Know — I set up a local webhook receiver to capture and document every event type Fizzy sends. The post covers the payload structures, signature verification, and ideas for what you could build on top of the webhook system.

The Making of Fizzy, Told by Git — I prompted Claude Code to analyze the entire git history and write a documentary about the development.

Vanilla CSS is all you need — Diving into the no-build CSS architecture across Campfire, Writebook, and Fizzy.

Fizzy Design Evolution: A Flipbook from Git — I went through each day of commits, got the application to a bootable state, seeded the database, and took a screenshot. Then I stitched those screenshots into a flipbook video with a soundtrack made from Fizzy’s own audio files.

Fizzy’s Pull Requests: Who Built What and How — An analysis of who owned which domains in the Fizzy codebase. The post maps contributors to their expertise areas and curates learning paths through the PRs for topics like Turbo/Hotwire, caching, AI integration, multi-tenancy, and webhooks.

Code

The open API invited experimentation. I spotted gaps that would make integration easier for other developers, so I filled them:

fizzy-api-client — Ruby client for the Fizzy API.

fizzy-client-python — Python client for the Fizzy API.

fizzy-cli — Command-line interface for the Fizzy API, built first in Ruby and then migrated to Go for portability.

fizzy-skill — An AI agent skill for interacting with Fizzy.

n8n-nodes-fizzy — An n8n community node that brings Fizzy into your automation workflows. Create cards, manage assignments, and react to real-time events through webhook triggers.

n8n Fizzy Node

Migration tools — I built these to make it easier to try Fizzy without starting from scratch. Migrating your existing issues and boards gives you an immediate sense of how it could work for you, without having to manually create test cards. You can see your real data running in Fizzy from day one, which I think makes it easier to evaluate and decide if its useful for you.

Contributions to Fizzy

I also contributed a few small fixes back to the main repository:

  • #2114 — Remove unused install.svg and its CSS class
  • #2111 — Remove unpaired view-transition-name
  • #2095 — Fix typo: minues → minutes
  • #2094 — Fix duplicate word: use use → use
  • #2093 — Add QrCodesController test
  • #2088 — Fix view-transition-name typo in public card show

O’Saasy Directory

Fizzy is released under the O’Saasy License, which is similar in spirit to MIT but includes a restriction on offering the software as a competing hosted or SaaS product. You can modify and self-host it, but you can’t repackage it and sell it as your own hosted service.

I built O’Saasy Directory to make it easy to find applications released under this license.

O'Saasy Directory

Beyond Fizzy, the directory includes other submitted projects where the source is available to read and modify. If you have built something under the O’Saasy License, visit the submission page to add yours.

CarbonationLabs

Having built the Fizzy CLI and fizzy-api-client Rubygem, I saw some fun opportunities to build little lab experiments to show how Fizzy could be integrated with - both to power up some functionality that isn’t there yet, but also creating boards in some interesting ways (eg Movie Quiz). I got the idea for this on a flight to Australia with no internet. Just a pad of paper and a pen. I should probably do that more often as a bunch of ideas for all sorts of products came out.

CarbonationLabs is not a product per se. It’s an open source Rails application designed to be run locally where you can interact with the hosted or self-hosted versions of Fizzy. If anything I hope it inspires creation of little problem solving workflows for Fizzy that wouldn’t be built into the main product (the problem is too niche). The API and webhook system is really flexible and most of your bespoke problems could be solved with some creative thinking.

carbonation.dev

I built carbonation.dev to bring together all the tools, libraries, and integrations that I and others in the community have created for Fizzy. It’s a directory covering API clients (Ruby, Python, JavaScript), CLI tools with packages for macOS, Arch Linux, Debian, Fedora, and Windows, integrations for Claude Code and other AI agents, n8n, Raycast, Telegram, and MCP servers, plus migration tools for GitHub, Linear, Asana, and Jira.

carbonation.dev

If you’ve built something for Fizzy, I’d love to feature it. You can submit a pull request to add your tool to the directory.

What I Learned

Building the Fizzy CLI pushed me into some new territory. I created an AUR package for Arch Linux users, set up a Homebrew tap for macOS, published my first Python package to PyPI, and made an n8n plugin — all firsts for me. While I already knew Go, rewriting the CLI in it was a fun exercise, and building TUIs for the setup and skill commands introduced me to terminal UI libraries I hadn’t used before. Gosh it was fun!

If you want to get better at Rails, Fizzy is a great place to study real-world code. And in my view if you want to work at 37signals as a Rails programmer, digging into Fizzy — along with Campfire and Writebook — is a solid way to learn how they approach Rails architecture and design decisions. Submitting PRs is also a good way to contribute back while learning — just be respectful of the contribution policy. The review discussions give you a window into how to reason about problems, spot opportunities, and make trade-offs.

This month pushed parts of my creative thinking that weren’t gone, but definitely weren’t being stressed. Like any muscle, use it or lose it. The direction of what to explore came from my own curiosity and a habit of poking around under the hood, and AI helped me move a lot faster once I knew where I wanted to go. Most of this information already exists somewhere — Google, Stack Overflow, documentation — but having AI right there alongside me as a partner was thrilling.

All of this was made possible because a team left the doors open. No one asked me to step inside; I decided to invest the time and do the work to see what I could build, learn and share. I do this at work too—when I can—looking for opportunities I can shape, experiment with, and get genuinely excited about. Most importantly I had fun and I hope you enjoyed following along.

What's Next: January is going to look a bit different. I'm planning to work on some AI skills and integrations for Omarchy, exploring whether natural language system administration is possible and effective — particularly with free models. I also want to dig into fine-tuning models, an area I haven't touched yet. And I'm curious about the new Qwen Image Layer model to see how well layered AI image manipulation works in practice. ✌