GForce on Rails vs. Hanami: Which Ruby Framework Aligns With a Zero-Waste Development Ethic?

Introduction: Beyond the Hype—Choosing a Framework for Long-Term Impact

Every Ruby developer eventually faces a crossroads: should you start a new project with the familiar, battle-tested Ruby on Rails, or invest time in the leaner, more deliberate Hanami? The question is rarely about which framework is objectively better—it is about which framework aligns with the values and constraints of your team, your product, and your commitment to sustainable development. This guide reframes the decision through a zero-waste development ethic, which prioritizes minimizing wasted cognitive effort, redundant code, and unnecessary resource consumption over the lifespan of a project.

We introduce the concept of "GForce"—an internal metric for assessing the gravitational pull a framework exerts on your architecture. A high-GForce framework (like Rails) pulls you into its conventions, speeding initial development but sometimes creating escape-velocity problems when you need to diverge. A low-GForce framework (like Hanami) offers less initial pull, demanding more deliberate architectural decisions from the start. Understanding this trade-off is central to making a choice that respects both your time and your project's future.

This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable. The goal is not to declare a winner, but to equip you with a decision framework that prioritizes long-term ethical software development over short-term convenience.

The Zero-Waste Development Ethic Defined

A zero-waste development ethic means treating code as a long-term asset, not a disposable commodity. Every line written incurs a cost: reading, understanding, testing, and eventually modifying or deleting it. Frameworks that encourage verbose configurations, magic behavior, or tight coupling increase this cost over time. Conversely, frameworks that promote explicitness, modularity, and minimalism reduce waste. This perspective values developer energy as a finite resource and seeks to maximize the impact of each unit of effort.

Why This Matters Now

As software systems age, the cost of maintenance often exceeds the cost of initial development. Teams that neglect this reality face burnout, technical debt spirals, and eventual rewrites. A zero-waste approach is not a luxury—it is a survival strategy for projects that aspire to endure for years, not just weeks. Choosing a framework that aligns with this ethic is one of the most consequential decisions a team can make, as it sets the trajectory for how easily the codebase can evolve.

Core Philosophy: How Rails and Hanami Define Productivity and Sustainability

At their core, Rails and Hanami represent two distinct philosophies about how to build web applications. Rails, created by David Heinemeier Hansson in 2004, is built on the principle of "convention over configuration." It assumes that a standard set of defaults will serve most projects well, and it provides an extensive toolkit (ActiveRecord, ActionPack, ActiveSupport) to accelerate development. Hanami, a newer framework (first stable release in 2017), takes a different approach: it emphasizes modularity, explicitness, and separation of concerns, even if that means writing more configuration code upfront.

From a zero-waste perspective, the question becomes: which philosophy generates less waste over a project's lifetime? Rails' conventions reduce boilerplate, which is a clear win for initial productivity. However, when a project inevitably outgrows a convention—say, needing a non-standard database schema or a custom authentication flow—the cost of deviating can be high. Developers often find themselves fighting against the framework's assumptions, leading to workarounds that increase complexity and technical debt. Hanami's modular design, on the other hand, makes it easier to swap out components (like the database adapter or view layer) without breaking the entire application. This flexibility can reduce waste in the long run, but it requires more upfront discipline and a deeper understanding of software architecture.

One team I read about, building a content management system for a mid-sized publisher, started with Rails because of its rapid prototyping capabilities. Within six months, they had a working product. However, as they added custom publishing workflows that diverged from Rails' RESTful defaults, they accumulated significant technical debt. The team spent the next year refactoring controllers and models to accommodate business logic that didn't fit the "skinny controller, fat model" pattern. In contrast, a different team building a similar system with Hanami from the start reported that their modular architecture allowed them to add those same custom workflows with minimal friction, because each component (authentication, content management, workflow engine) was already decoupled.

Convention vs. Configuration: The Waste Trade-Off

The "convention over configuration" mantra saves time when you stay within the lines, but it can create waste when you need to leave them. Consider the case of database migrations. Rails' ActiveRecord assumes a single database connection and a relational schema. If your project later requires a NoSQL component or multiple databases, you must introduce additional gems and work around ActiveRecord's assumptions. Hanami's repository pattern, by contrast, abstracts the persistence layer more cleanly, making it easier to change databases or use multiple data stores without rewriting business logic. This architectural flexibility is a direct reduction in future waste.

Modularity as an Ethical Choice

Choosing a modular framework like Hanami can be seen as an ethical decision because it respects the future developer (who may be you, six months from now) by making the system easier to understand and change. Modularity reduces the cognitive load required to reason about the codebase, which in turn reduces the likelihood of introducing bugs during maintenance. It also makes it easier to test components in isolation, leading to more reliable software. From a sustainability standpoint, a modular codebase is like a well-designed building with accessible wiring and plumbing—it can be repaired and extended without tearing down walls.

GForce on Rails: The Gravitational Pull of a Mature Ecosystem

The term "GForce" captures the magnetic attraction that Rails exerts on its ecosystem. When you adopt Rails, you are not just adopting a framework; you are adopting a whole philosophy of how code should be organized, how tests should be written, and how deployments should work. This is both a strength and a liability. The strength is that new developers can join an existing Rails project and quickly understand its structure because they already know the conventions. The liability is that those conventions can become an invisible cage, trapping the project in patterns that may not serve its long-term needs.

From a zero-waste perspective, Rails' high GForce means that initial development is highly efficient—you can generate models, controllers, and views with a single command. This rapid start reduces the waste of "analysis paralysis" and gets a working prototype into users' hands quickly. However, as the project grows, the gravitational pull can lead to "framework lock-in." For example, if your business logic becomes deeply entangled with ActiveRecord callbacks and validations, extracting that logic into a separate service or gem becomes a significant refactoring effort. This entanglement is a form of waste: it consumes developer time that could have been spent on new features or improvements.

Another common example is the use of Rails' asset pipeline (now largely replaced by Webpacker or import maps in modern Rails). While these tools are convenient for bundling JavaScript and CSS, they also tie the frontend build process to the Rails ecosystem. If a team later decides to adopt a JavaScript framework like React or Vue.js, they often need to add additional gems (like react-rails) and navigate the complexities of server-side rendering versus client-side rendering. This integration work is waste—it doesn't directly serve the user, but it is necessary to make the tools work together. Hanami's more explicit separation between the web layer and the business logic layer reduces this kind of friction.

When High GForce Works Well

Rails excels in scenarios where the problem domain aligns closely with its conventions. Standard CRUD applications, content management systems with straightforward models, and e-commerce platforms that follow typical patterns are all well-served by Rails. The framework's mature ecosystem (gems like Devise for authentication, CanCanCan for authorization, and Sidekiq for background jobs) reduces the need to reinvent the wheel. In these cases, the waste saved by using pre-built solutions outweighs the waste incurred by future deviations.

When High GForce Creates Problems

Problems arise when the project's requirements diverge significantly from Rails' assumptions. For example, a team building a real-time collaboration tool (like a shared document editor) might struggle with Rails' synchronous request-response model. They would need to introduce ActionCable (Rails' WebSocket solution), which adds complexity to the deployment and scaling story. Similarly, a project that requires complex domain logic with many interacting entities may find that Rails' Active Record pattern leads to increasingly unwieldy models. In these situations, the cost of fighting the framework's gravity can exceed the initial productivity gains.

Hanami: A Deliberate Choice for Sustainable Architecture

Hanami (formerly known as Lotus) was created with explicit goals of simplicity, modularity, and maintainability. Unlike Rails, which prioritizes developer happiness through convention, Hanami prioritizes developer happiness through clarity and control. Its architecture is based on several key principles: each component (models, views, controllers) is a standalone Ruby class, not a module mixed into a base class; the framework uses dependency injection to manage dependencies, making components testable in isolation; and the persistence layer is separated from the domain logic through a repository pattern, rather than the Active Record pattern of mixing data access into model objects.

From a zero-waste perspective, Hanami's design reduces waste in three critical areas. First, its explicitness reduces cognitive waste: when you read a Hanami controller or model, you can see exactly what it does without needing to know about inherited behavior from the framework. Second, its modularity reduces rework waste: if a component needs to be changed or replaced, the impact is localized, not system-wide. Third, its emphasis on domain logic purity reduces testing waste: because business logic is not tangled with framework concerns, unit tests are simpler, faster, and more reliable. These benefits compound over time, making Hanami an attractive choice for projects with a long expected lifespan.

However, Hanami is not without its own forms of waste. The initial setup requires more explicit configuration—defining routes, specifying dependencies, and wiring up repositories. For a simple five-table application, this can feel like unnecessary ceremony. The gem ecosystem is smaller than Rails', meaning that teams may need to build more from scratch or integrate third-party libraries with less handholding. The learning curve is steeper for developers accustomed to Rails' magic, and the community is smaller, making it harder to find solutions to edge cases. These factors can create waste during the initial development phase, especially for less experienced teams.

One composite example illustrates the trade-off: a team building a financial analytics dashboard chose Hanami because the domain logic was complex and stable (it dealt with regulatory calculations that changed infrequently but had to be absolutely correct). The team reported that Hanami's separation of concerns made it straightforward to test the calculation engine independently of the web interface, and when a regulatory change required updating the calculation logic, they could do so without touching the controller or view code. In contrast, a comparable Rails project that the same team had worked on previously required changes to models, controllers, and helpers whenever the business rules changed, creating a higher risk of introducing bugs.

Hanami's Interactor Pattern: Reducing Waste in Business Logic

Hanami provides an "interactor" pattern for organizing complex business operations. An interactor is a plain Ruby object that encapsulates a single use case (like "create an order" or "process a refund"). This pattern reduces waste by enforcing a clear boundary between the request handling (controller) and the business logic (interactor). It also makes it easy to compose interactors for more complex workflows, and to test each use case in isolation. This is a stark contrast to Rails' tendency to place business logic in models or controllers, which leads to fat models and the "god object" anti-pattern.

The Cost of a Smaller Ecosystem

Teams considering Hanami must account for the smaller gem ecosystem. For common needs like authentication, there is no single canonical gem; teams may need to build their own solution or adapt a Rails gem. This upfront investment can be significant, especially for a small team. However, this investment can also be seen as a form of waste reduction: building your own authentication system from scratch using Hanami's modular patterns often results in code that is simpler, more secure, and easier to audit than a Rails gem that tries to handle every conceivable edge case. The trade-off is between initial effort and long-term control.

Head-to-Head Comparison: A Framework for Decision-Making

To make an informed choice, it helps to see the two frameworks side by side across the dimensions that matter most for zero-waste development. The table below compares Rails and Hanami on eight key criteria, each of which contributes to the total waste generated by a project over its lifetime. Use this comparison as a starting point for your own evaluation, but remember that your specific context (team size, project lifespan, domain complexity) will ultimately determine which framework is the better fit.

Interpreting the Table: Waste as a Multiplier

The table shows that no framework is universally low-waste. Rails minimizes waste in the short term but can accumulate it over time, especially if the project diverges from conventions. Hanami demands more upfront investment but tends to generate less waste in the long term. The key insight is that waste compounds: a small amount of extra waste in the first month (from Hanami's configuration) can be dwarfed by the waste saved in the third year (from easier refactoring). Therefore, the decision should be based on the expected lifespan and evolution trajectory of the project. For a prototype that may be discarded in six months, Rails' low initial waste is the clear winner. For a core business system expected to last five years or more, Hanami's long-term benefits may outweigh its initial costs.

GForce as a Diagnostic Tool

The concept of GForce can also be used diagnostically. If you are already using Rails and finding that your project's codebase feels increasingly brittle, with changes in one area causing unexpected failures in another, it may be a sign that the framework's gravitational pull has become a liability. In such cases, it may be worth considering a gradual migration toward a more modular architecture—perhaps by extracting services into Hanami-style interactors or by using Hanami for new subdomains within a larger project. This incremental approach can reduce the waste of a full rewrite while still moving toward a more sustainable architecture.

A Step-by-Step Decision Framework for Zero-Waste Framework Selection

Making a deliberate choice between Rails and Hanami requires more than reading comparisons—it requires a structured evaluation of your specific context. The following step-by-step guide is designed to help you apply the zero-waste ethic to your own decision. By the end of this process, you should have a clear sense of which framework will generate the least total waste for your project over its expected lifetime. Adapt these steps to your team's size, risk tolerance, and domain constraints.

Step 1: Define Your Project's Expected Lifespan and Evolution Path

Start by asking: is this a short-lived prototype, an MVP that may pivot significantly, or a core system intended to operate for years? For prototypes, Rails' rapid development is almost always the right choice. For long-lived systems, consider Hanami's architectural sustainability. Also consider the evolution path: will the system likely need to integrate with other services, support multiple clients, or adapt to changing business rules? Systems with high evolution potential benefit from Hanami's modularity.

Step 2: Assess Your Team's Experience and Learning Capacity

An experienced team that is comfortable with software architecture principles (dependency injection, repository patterns, decoupled design) will find Hanami's learning curve manageable. A team that is newer to Ruby or web development may struggle with Hanami's explicitness and prefer Rails' conventions. Be honest about your team's current capabilities and their ability to invest in learning a new paradigm. The waste of a steep learning curve can be significant if it delays delivery or reduces code quality.

Step 3: Map Your Core Business Logic Complexity

If your application's value lies in complex domain logic (e.g., financial calculations, medical algorithms, custom workflows), Hanami's emphasis on separating domain logic from framework concerns is a strong advantage. If your application is primarily a thin CRUD layer over a database (e.g., a blog, a simple e-commerce store), Rails will serve you well with less waste. Draw a simple diagram of your core entities and their interactions—if there are many non-trivial business rules, lean toward Hanami.

Step 4: Evaluate the Cost of Deviating from Conventions

For Rails, ask: what percentage of your features will likely follow standard RESTful patterns? If the answer is less than 80%, be prepared for the cost of fighting Rails' conventions. For Hanami, ask: how much upfront configuration are you willing to accept for the benefit of long-term flexibility? If your team values speed of initial development above all else, Hanami may feel like unnecessary overhead. Create a simple checklist of your top five non-standard features and estimate the effort to implement them in each framework.

Step 5: Prototype a Critical Feature in Both Frameworks

The most reliable way to compare frameworks is to build a small but representative piece of your application in each. Choose a feature that exercises the core of your architecture (e.g., a complex form submission with validation, a multi-step workflow). Time the implementation, note the pain points, and evaluate the resulting code for clarity and testability. This hands-on comparison will reveal the true waste trade-offs for your specific context, far more accurately than any general guide can.

Step 6: Make a Decision and Commit, but Leave Room to Adapt

Once you have completed the evaluation, make a decision and commit to it. Avoid the waste of indecision or of switching frameworks mid-project without a compelling reason. However, also design your architecture to be somewhat framework-agnostic: use Hanami-style interactors for business logic even if you choose Rails, and keep your domain models free of framework dependencies. This insurance policy reduces the waste of a future migration, should you ever need to make one.

Real-World Scenarios: When Each Framework Shines and Struggles

To ground the theoretical discussion, consider three composite scenarios drawn from patterns observed in real development teams. These scenarios are anonymized to protect specific identities, but they reflect common challenges that arise when the framework choice is misaligned with the project's needs. Each scenario highlights a different aspect of the waste trade-off and offers lessons for decision-making.

Scenario 1: The Rapid Prototype That Became a Production System (Rails Success Story)

A small startup needed to launch a minimum viable product within two months to secure funding. They chose Rails for its speed of development, using Devise for authentication, ActiveAdmin for an admin panel, and Heroku for deployment. The prototype was built in six weeks and successfully demoed to investors. Over the next two years, the startup grew to ten developers, and the Rails codebase evolved with the product. While there were moments of friction (e.g., when they needed to add custom reporting that didn't fit ActiveAdmin's patterns), the team found that Rails' conventions helped new hires onboard quickly. The key to their success was that they disciplined themselves to extract business logic into plain Ruby classes early, preventing fat models from becoming unmanageable. This hybrid approach—Rails for the web layer, plain Ruby for the domain—reduced the waste of fighting the framework while preserving its productivity benefits.

Scenario 2: The Complex Domain That Outgrew Rails (Migration to Hanami)

A medium-sized company built a regulatory compliance platform using Rails. Initially, the six-person team was productive, but as the platform expanded to handle dozens of regulatory frameworks, the Rails models became massive, with hundreds of callbacks, validations, and associations. Testing became slow and brittle, and every deployment carried a risk of breakage. The team decided to migrate the core domain logic to Hanami, keeping a Rails frontend for the existing admin interface. The migration took three months and was painful, but it paid off: the Hanami domain code was easier to test, new regulatory rules could be added without touching the web layer, and the team's confidence in their deployments increased. The lesson is that recognizing the waste of a misaligned framework early—and being willing to invest in a migration—can prevent years of accumulated technical debt.

Scenario 3: The Wrong Tool for the Job (Hanami for a Simple CRUD App)

A solo developer building a personal blog opted for Hanami because they admired its clean architecture and wanted to learn something new. However, the blog had no complex logic—just posts, comments, and tags. The developer spent two weeks configuring Hanami's repositories, setting up dependency injection, and wiring up routes, when Rails would have produced a working blog in an afternoon. The extra configuration was waste that didn't serve the project's needs. The developer eventually switched to Rails and completed the blog in a weekend. The lesson is that Hanami's strengths are wasted on simple projects, and its initial overhead becomes pure waste when the domain doesn't require its modularity. This scenario reinforces the importance of matching framework complexity to project complexity.

Common Questions and Concerns About Framework Choice and Sustainability

Even with a structured decision framework, teams often have persistent questions about the practical implications of choosing Rails or Hanami. This section addresses the most common concerns from a zero-waste perspective, providing nuanced answers that acknowledge the trade-offs involved.

Will choosing Hanami make it harder to hire developers?

This is a legitimate concern. The Rails developer pool is significantly larger than Hanami's. If your team needs to scale rapidly and hire many developers, Rails offers a lower barrier to entry. However, consider the quality of the hire: a developer who is eager to learn Hanami is likely someone who cares about software architecture and long-term quality, which aligns with a zero-waste ethic. The waste of a smaller talent pool may be offset by the reduced waste from having more disciplined, architecture-aware developers on your team. If hiring is a critical constraint, Rails is the safer choice, but do not underestimate the value of a team that genuinely understands and values clean architecture.

Can I use Hanami and Rails together in the same project?

Yes, it is possible to run both frameworks within the same application, though it requires careful setup. For example, you could use Rails for the public-facing web interface and Hanami for a background job processor or an internal API. This hybrid approach can be a practical migration strategy: you can start with Rails and gradually extract services into Hanami as the need arises. However, maintaining two frameworks in one codebase introduces its own waste (two sets of conventions, two dependency management systems, two testing patterns). Use this approach only when the benefits of migration clearly outweigh the overhead of maintaining both frameworks.

Which framework is more future-proof?

Neither framework is inherently future-proof, but they are future-proof in different ways. Rails is future-proof because of its massive community and ecosystem—it is unlikely to be abandoned, and there will always be developers who know it. Hanami is future-proof because of its architectural principles—even if the framework itself loses popularity, the patterns it teaches (modularity, dependency injection, separation of concerns) are timeless and transferable to other languages and frameworks. From a zero-waste perspective, investing in Hanami-like architecture (even within a Rails project) is the best insurance against technological obsolescence.

Does the choice affect environmental sustainability?

Indirectly, yes. A codebase that is easier to maintain requires fewer compute resources to test, deploy, and run because there is less redundant code and fewer unnecessary operations. A well-architected Hanami application may use fewer server resources than a Rails application with the same functionality, because the modular design makes it easier to optimize specific components. However, the difference is typically marginal compared to the environmental impact of developer travel, office energy use, and cloud infrastructure. The more significant environmental benefit comes from reducing developer burnout and turnover, which are major sources of waste in the software industry. A framework that aligns with a zero-waste ethic is also a framework that supports a healthier, more sustainable team culture.

Conclusion: Making a Choice That Respects Your Future Self

The decision between Rails and Hanami is ultimately a decision about how you want to spend your development energy over the lifetime of a project. Rails offers a boost of initial momentum, powered by its conventions and ecosystem, but that momentum can become a trap if your project's needs diverge from the framework's assumptions. Hanami requires a stronger initial push, but its modular architecture makes it easier to change direction without breaking the system. From a zero-waste development ethic, the right choice depends on the balance between short-term and long-term waste.

For projects with a short expected lifespan, simple domain logic, or a team that values speed above all else, Rails is the low-waste choice. For projects with a long expected lifespan, complex domain logic, or a team that prioritizes maintainability and architectural integrity, Hanami is the low-waste choice. In many cases, the best answer is a hybrid: use Rails for the web layer and rapid prototyping, but adopt Hanami-inspired patterns (interactors, repositories, dependency injection) for your business logic. This approach gives you the best of both worlds: the productivity of Rails when you need it, and the sustainability of clean architecture when you need it.

Ultimately, the most important step is to make a deliberate, informed choice rather than defaulting to the framework you already know. By applying the zero-waste ethic—asking where waste will accumulate and how to minimize it—you can build software that respects your own time, your team's energy, and the long-term health of the systems you create. The choice is not just about code; it is about the kind of developer you want to be and the legacy you want to leave in your codebase.

As you evaluate your next project, remember that the framework is a tool, not a master. The best architecture is the one that serves your users and your team for as long as it needs to. Choose wisely, and build sustainably.