I've been thinking about building a small internal tool for the team—a "Coffee Intake Tracker." The goal is simple: a way for us to log how many espressos we've had so we know when to stop talking about refactoring the codebase and actually go take a nap. I want to get this live today, but I'm torn on which tool to use.

The "I just need it to work" approach

My first instinct is to go as lean as possible. I don't want to spend an hour configuring a directory structure just to return a JSON string. So, I'll start with Sinatra. I'll just throw everything into one file and see how it feels.

require 'sinatra'
require 'json'

coffee_logs = []

post '/log' do
  content_type :json
  payload = JSON.parse(request.body.read)
  coffee_logs << { user: payload['user'], cups: payload['cups'], time: Time.now }
  { status: 'success' }.to_json
end

get '/stats' do
  content_type :json
  coffee_logs.to_json
end

This is great. I ran `ruby app.rb` and it's working. No boilerplate, no "magic" folders, just a route and a block of code. But here's where the friction starts: I realize I need a database, a way to handle user authentication, and maybe a simple HTML dashboard to show the team's caffeine levels. Suddenly, I'm manually requiring gems, setting up ActiveRecord connections, and my single file is becoming a 400-line monster. I'm spending more time deciding where the code should go than actually writing the features.

Attempting to find a middle ground

I've heard that Hanami is the answer for people who hate the "bloat" of Rails but find Sinatra too naked. It emphasizes "Clean Architecture," meaning it separates the web layer from the actual business logic. Let's see if that solves my organization problem.

I set up a Hanami project and notice immediately that it's very different. Instead of a giant controller, I have "Actions." Each route has its own class. I'm thinking, "This is perfect. My LogCoffee action is isolated from my ViewStats action."

# app/actions/coffee/create.rb
module CoffeeTracker
  module Actions
    module Coffee
      class Create < Hanami::Action
        def handle(request, response)
          # The business logic stays in a separate 'Repository' 
          # or 'Interactor' class.
          repository = CoffeeRepository.new
          repository.create(request.params[:coffee])
          response.status = 201
        end
      end
    end
  end
end

I love the discipline here. It forces me to keep my logic out of the routing layer. However, I'm starting to feel the weight of the ceremony. I'm creating three files and two modules just to save a single record to a database. For a massive enterprise app, this decoupling is a lifesaver. For my coffee tracker? I'm spending way too much time typing module and class keywords.

Giving in to the "Magic"

At this point, I'm frustrated. Sinatra was too loose; Hanami is too rigid for this specific scale. I decide to just spin up a Rails app. I run `rails new coffee_tracker` and `rails generate scaffold Coffee user:string cups:integer`.

In about thirty seconds, Rails has given me the database migration, the model, the controller, the views, and the routes. It's an enormous amount of code I didn't write, and some of it is totally unnecessary for this app. But here's the realization: because Rails follows "Convention over Configuration," I don't have to think about where the files go. I don't have to debate the architecture. I just use the patterns that thousands of other developers already know.

I'm looking at the three of them now, and the choice becomes clear based on the "cognitive load" I'm willing to take on:

• Sinatra: I use this when the app is essentially a "wrapper" around a single function or a tiny API. If the project fits in one or two files, Sinatra is the winner.
• Hanami: I use this when I'm building a long-term, complex system where I want to avoid the "Rails Monolith" problem. It's for when I care more about architectural purity and testability than development speed.
• Rails: I use this when I need a full-featured application and I want to get to market (or production) as fast as possible. The "magic" is a trade-off: you lose some transparency, but you gain an incredible amount of velocity.

For my coffee tracker, I'll stick with Rails. I don't need to be an architect today; I just need to know how much caffeine my coworkers are consuming.

📋 Practical Task

Building a Lightweight System Health-Check API with Sinatra

You need to build a very small utility service that monitors the health of three different external APIs. This is a perfect use case for Sinatra because it requires minimal logic and no complex database architecture.

Requirements:

• Create a Sinatra application with a single GET route at /health.
• The route should check the status of three URLs (you can use https://google.com, https://github.com, and https://ruby-lang.org as placeholders).
• Use the net/http standard library to check if the responses are 200 OK.
• Return a JSON object where the keys are the site names and the values are either "UP" or "DOWN".
• Set the content_type to :json so the browser/client interprets the response correctly.