RocketApex open source is not a trophy shelf. These are small, usable libraries extracted from real product and platform work, released so other Rails teams can solve similar problems with less ceremony.
Each project is intentionally narrow. The goal is to make one repeated job easier without hiding the Rails application behind a heavy framework.
A small JavaScript lifecycle layer for Rails and Turbo applications, positioned as an explicit component-class alternative to Stimulus.
Useful when a Rails team wants class-based browser behavior, Turbo-aware lifecycle hooks, and importmap-friendly JavaScript without turning the frontend into a separate app.
A Rails gem for rendering page titles, meta tags, Open Graph tags, Twitter cards, breadcrumbs, and useful Schema.org JSON-LD from small page objects.
Useful when marketing pages, articles, case studies, and product pages need consistent metadata without hand-building tags in every template.
A Rails gem for getting model-like behavior without saving records to the database.
Useful for contact forms, lead forms, request objects, and service-layer inputs where validations matter but persistence belongs somewhere else.
Public tools are one way to show how we think about maintainability, release discipline, and Rails ergonomics before a consulting conversation starts.
We prefer small gems with installable releases, changelogs, tests, and practical README examples over vague experiments.
The best open-source utilities come from repeated project pressure: metadata, form objects, Turbo lifecycle behavior, and Rails engine integration.
Public APIs should stay boring, documented, and compatible enough that future Rails upgrades do not become archaeology.
The same habits behind these gems show up in our product engineering, platform modernization, and Rails engine work: small surfaces, clear contracts, tests, and release paths.
