Fizzy's Pull Requests: Who Built What and How

Sifting through Fizzy’s pull requests, it was fascinating to see how the 37signals team thinks through problems, builds solutions, and ships software together. Outside of their massive contributions to open source libraries, the podcast and the books — this was a chance to see up close, with real code, the application building process.

Below you will read which 37signals team members owned which domains in this project, and which PRs best demonstrate their craft. If you’re new to the codebase (or want to level up in specific areas), I will point you to the PRs worth studying. Each section highlights an engineer’s domain knowledge and the code reviews that showcase their thinking.

Why Read Pull Requests?

Reading the code shows the outcome. Pull requests show the decisions.

I love reading PRs because they reveal the reasoning behind the work, the options considered and the tradeoffs made. Review comments often become real lessons as people question choices, suggest alternatives, and offer encouragement.

These reviews can create quick, informal mentorship where one person spots a cleaner abstraction and another catches an edge case before it slips through.

Follow a codebase through its PRs and you can see the product being built in real time as early spikes set patterns, refactors clear debt, and new features rise on earlier work.

Want to dive into a specific topic? Jump to the Learning Paths for curated PR sequences on AI/LLM integration, multi-tenancy with SQLite, Turbo/Hotwire, and more.

DHH (David Heinemeier Hansson)

Expertise: Rails Architecture, Code Style, API Design

DHH’s code reviews are masterclasses in Rails conventions. His 20 PRs and numerous reviews establish patterns the whole team follows. I believe this is the first publicly viewable application codebase where we see DHH doing code reviews — well worth the time to dig into those and see his thinking for yourself.

Must-Read PRs

PR #108 - Spike events system (reviewed)

This PR establishes core architectural patterns. Key feedback:

On delegated types and pagination:

“These threads need to be paginated, so you can’t do any in-memory sorting. This all needs to be converted to a delegated type, so you have a single table you can pull from.”

On lazy loading:

“Why not just delegate :user to :session? Then you get to lazy load it too.”

On naming conventions:

“not_popped is pretty cumbersome of a word. Consider something like unpopped if staying in the negative or go with something like active.”

On test-induced design damage:

“I think that would then qualify as test-induced design damage. Better replace that with a mock or even better just a fixture session you can use. We should never let our desire for ease of testing bleed into the application itself.”

PR #120 - Use the new params#expect syntax

Demonstrates DHH’s preference for Rails’ built-in features:

“To ensure we don’t get spurious 500s when we can serve 400s on bad data.”

PR #119 - Start adding caching

Foundation for Fizzy’s caching strategy.

PR #425 - Plain text mentions (reviewed)

Key feedback on code style:

On method naming:

“collect implies that we’re returning an array of mentions (as #collect). Would use create_mentions when you don’t care about the return value.”

On Rails built-ins:

“You can use after_save_commit instead of after_commit on: %i[ create update ].”

On API design:

“Bit too heavy-handed, imo. Better to make action return a StringInquirer. Then you can do event.action.completed?.”

DHH’s Style Patterns

Prefer delegation over accessor methods
Use Rails’ built-in features (StringInquirer, counter caches, after_save_commit)
Name methods by what they do, not what they return
Avoid test-induced design damage
Extract explaining methods for complex logic

Jorge Manrubia

Expertise: Turbo/Hotwire, Caching, AI/LLM Integration, ActiveRecord Patterns

With 285 PRs, Jorge is the most prolific backend contributor. His deep knowledge spans Hotwire, caching strategies, and AI integration.

Must-Read PRs

PR #339 - Enable page refreshes with morphing

Introduction of Turbo morphing for smoother updates:

“This makes the update actions on cards feel smoother.”

PR #483 - Fizzy Do with AI

A complete guide to integrating LLMs in Rails:

“Adds LLM processing to the Fizzy Do bar, enabling:

Filtering cards using natural language. E.g: cards assigned to jz.

Act on cards using natural language: E.g: close cards assigned to jz.

Get insight on cards: E.g: summarize this card.”

Key implementation details:

Using ruby_llm gem for model flexibility
Translating natural language to commands via structured output
Vector embeddings with SQLite-vec extension
Token limit handling

PR #1052 - Add more caching

HTTP caching and server-side template caching patterns:

“When rendering a day timeline, we:

HTTP cache the full request.

Cache the filter menu.

Cache the columns of events (so this could be shared across users who see the same set of events).

We leave out things like the day header, since this can vary on a per-user basis (e.g: timezones)”

PR #929 - Conversation cost limits (reviewed)

Jorge’s review demonstrates advanced patterns:

On extracting models:

“The shared param is often a smell that something is missing. My mind goes to having a new record Ai::Quota so that each user has a quota. The quota has an amount that gets reset weekly in a cron job.”

On custom ActiveRecord types:

“If you wanted to make an AR attribute, you can use a custom Active Model/Record type; there is first-class support for it. You can define a type, register it, and then declare attributes with it.”

On the .wrap convention:

“We have the internal in-house convention of using a static method .wrap when you want to get an object from several different types values.”

Jorge’s Patterns

Memoize expensive computations called multiple times per render
Use transient filters for temporary state
Consider cache keys carefully (user-specific vs. shared)
Extract concerns when responsibilities become clear
Use Stimulus values API over arbitrary data attributes

Mike Dalessio

Expertise: Infrastructure, Solid Queue, Dependencies, AI/Parsing, DevOps

With 317 PRs, flavorjones handles the infrastructure backbone: dependencies, background jobs, deployment, and parsing.

Must-Read PRs

PR #457 - Recursive descent parser for Fizzy Do

Hand-written parser design:

“Using a hand-written recursive descent parser instead of a LALR parser generator (like lex/yacc or rex/racc) because IMHO it’s easier to understand, extend, and debug. It also allows us to be a bit more error-tolerant where we need to.”

“The AST I’m introducing here is pretty simple, and I’m not tracking token location because my assumption is that the parsed strings are all going to be short.”

PR #159 - Introduce tenanting

Multi-tenant SQLite architecture with comprehensive documentation:

“This PR does a few notable things to implement a tenanted sqlite3 database for Fizzy:

Introduce a Tenant model in a non-tenanted secondary database

Tenant the ApplicationRecord models using active_record-tenanted

Introduce middleware for selecting the tenant based on subdomain

Extend the ‘first run’ flow to include a subdomain field

Modify TestCase to handle parallel testing”

Design decisions documented:

Subdomain vs URL path tenanting
Slug separate from database name for changeability
SecureRandom for permanent database file names

PR #1109 - Yabeda for Solid Queue metrics

Monitoring background job infrastructure.

PR #501 - Stimulus controller for bubbles

Learning Stimulus through code review. Jorge’s feedback:

“Consider using Stimulus values instead of arbitrary data properties. It’s not a life-changing improvement, but nice to use what’s available and the API is nice. You would be able to do this.closeAtValue to read the attribute.”

“In javascript, our convention is closesAt instead of closes_at.”

flavorjones’s Patterns

Structured logging with tenant context
Careful dependency management (Rails edge testing)
Comprehensive test helpers for complex infrastructure
VCR cassettes for AI/external API testing
Clear PR descriptions explaining design decisions

Jason Zimdars

Expertise: UI/UX Design, CSS Architecture, ERB Templates, Filtering Systems

217 PRs focused on design implementation. JZ bridges design and code.

Must-Read PRs

PR #305 - New visual design - Complete UI overhaul that defined Fizzy’s visual language
PR #131 - New filtering UI - Filter interface patterns
PR #335 - Two column Collection design - Layout architecture decisions
PR #265 - Quick filters - User-facing filter shortcuts
PR #608 - Add multiple cards quickly - Rapid input UX patterns

JZ’s Patterns

CSS file structure by component
Visual documentation via screenshots in PRs

For more on Fizzy’s CSS approach, see my post Vanilla CSS Is All You Need.

Stanko Krtalic Rusendic

Expertise: Webhooks, Authentication, Security, External Integrations

76 PRs with deep focus on external system integration and security.

Must-Read PRs

PR #1083 - Webhooks

Comprehensive webhook implementation:

“Webhooks hook into the events model. For every event that’s created a WebhookDispatch job is spawned that checks which webhooks should get triggered.”

Security mechanisms:

HMAC SHA256 signing for verification
Timestamps to prevent replay attacks
URL resolution checking for loopback/private networks (SSRF protection)
Delinquent webhook auto-deactivation

“I used the limits concurrency method here to preserve causality as much as possible. It’s not a guarantee that the hooks will get delivered in order, but it helps preserve the order in most cases.”

PR #929 - Conversation cost limits

AI quota management with Money value object:

“We still aren’t sure how much Fizzy Ask is going to cost us, so to keep cost under control I’ve added a cost limit per conversation.”

Implementation details:

Quota tracking per user
Weekly reset periods
Money object for microcent calculations
Clear error messaging for users

PR #1304 - Magic links

Passwordless authentication with security considerations. Key discussion from flavorjones:

“One thing I’m nervous about here is the loss of authentication per account. It’s possible that an Identity (a person) would have multiple accounts under multiple email addresses… compromising one of those email addresses exposes all of those Fizzy accounts.”

monorkin’s Patterns

Security-first design (SSRF checks, signing, rate limits)
Detailed PR descriptions with implementation rationale
State machine patterns for deliveries (pending, in_progress, completed, errored)
Active Job Continuations for reliable delivery

Andy Rankin

Expertise: CSS/Styling, Stimulus Controllers, UI Components, Accessibility

With 268 PRs, Andy is the third most prolific contributor, focused entirely on frontend implementation.

Must-Read PRs

PR #962 - Combobox a11y - Accessibility patterns for complex components
PR #920 - Popup orientation - Positioning logic for popups
PR #1199 - Column animation - CSS animation patterns
PR #1187 - Save expanded state to localStorage - Client-side state persistence
PR #836 - Lightbox improvements - Image viewing UX
PR #379 - Btn dropdown - Dropdown component patterns

Andy’s Patterns

Component-focused CSS organization
Accessibility-first approach
localStorage for UI state persistence
Stimulus controllers for interactive behavior

Other Key Contributors

Jose Farias

Expertise: Filtering Systems, Form Handling, Early Architecture

23 PRs establishing core patterns in Fizzy’s early development.

PR #113 - Persisted filters - Filter state management
PR #124 - Build threads from a single table - Delegated types implementation
PR #135 - Counter cache for comments - ActiveRecord counter cache patterns

Kevin McConnell

Expertise: Infrastructure, Notifications, Deployment, Performance

49 PRs focused on operational concerns.

PR #199 - Notification spike - Notification system foundation
PR #274 - Notification preferences - User preference architecture
PR #1377 - Extend public caching to 30 seconds - HTTP caching for CDN optimization

Jeremy Daer

Expertise: Security, Ruby Infrastructure, DevOps

36 PRs with security focus.

PR #1903 - Security: DNS rebinding protection - Closing security vulnerabilities
PR #1905 - Security: Web Push SSRF - SSRF mitigation patterns
PR #1964 - Content Security Policy - CSP implementation

Rosa Gutierrez

Expertise: CSRF Protection, Security Headers

PR #1721 - Sec-Fetch-Site header reporting - Modern browser security header usage
PR #1751 - Sec-Fetch-Site CSRF protection - Moving from report-only to enforcement

Topic-Based Learning Paths

Fizzy's Pull Requests: Who Built What and How

Why Read Pull Requests?

Must-Read PRs

PR #108 - Spike events system (reviewed)

PR #425 - Plain text mentions (reviewed)

DHH’s Style Patterns

Must-Read PRs

PR #929 - Conversation cost limits (reviewed)

Jorge’s Patterns

Must-Read PRs

flavorjones’s Patterns

Must-Read PRs

JZ’s Patterns

Must-Read PRs

monorkin’s Patterns

Must-Read PRs

Andy’s Patterns

Other Key Contributors

Topic-Based Learning Paths

Turbo/Hotwire

Stimulus

Rails Caching

AI/LLM Integration

Multi-tenancy (SQLite)

Webhooks & External APIs

Security

Notifications

Background Jobs (Solid Queue)

Filtering & Search

Active Storage & Attachments

Action Text & Rich Content

Real-time (Action Cable & Web Push)

Email (Action Mailer)

Performance Optimization

Observability & Monitoring

Concern Extraction & Refactoring

Workflows & State Machines

Auto-close & Entropy System

Keyboard Navigation & Accessibility

Mobile & Responsive Design

Watching & Subscriptions

Credentials & Configuration

Drag & Drop