Forem: The One-Man Framework

The Art of Deleting Code: Why Your One-Man App Should Be Shrinking

The One-Man Framework — Thu, 21 May 2026 22:06:26 +0000

Most developers think that "progress" means adding lines of code. We feel good when we finish a new feature, add a new gem, or create a new database table. We think we are building an empire.

But as a solo developer, you need to realize a painful truth: Every line of code you write is a liability.

Every line of code is something you have to debug, something you have to upgrade when Rails 9 comes out, and something that takes up space in your brain. If your app grows too large, you will eventually hit "Context Bankruptcy" - you will be too afraid to change anything because you don't remember how the whole system fits together.

In 2026, the most important skill for a solo dev is not writing code, but ruthlessly deleting it. Here is how I keep my apps small, fast, and manageable.

1. The "Feature Funeral"

We often build features because we think users want them. Six months later, we look at the database and realize only 2 people have ever clicked that button.

Most developers leave that code there "just in case."
Don't.

If a feature isn't providing core value, delete the controller, delete the views, and drop the database columns. If you feel bad about it, remember that the code still exists in your Git history. You can always go back and find it later. Deleting unused features reduces the number of "moving parts" you have to keep in your head.

2. Pruning the "Gem Forest"

I used to be a "Gem Addict." I would add a gem for every little problem.
Need to format a phone number? Add a gem.
Need a simple slider? Add a heavy JS library.

In Rails 8, we have so many built-in tools that many old gems are now useless.

Solid Queue means you can delete sidekiq and redis.
Importmaps means you can delete webpacker and package.json.
Native Authentication means you can delete devise.

Every gem you delete makes your bundle install faster and reduces the risk of security vulnerabilities. Once a month, I run bundle pristine and look through my Gemfile to see what I can replace with 10 lines of plain Ruby.

3. Cleaning up "AI Slop"

If you use AI tools like Cursor or ChatGPT, you are generating code faster than ever before. But AI is "wordy." It will often write a 50-line method to solve a problem that only needs 10 lines. It adds extra "safety checks" and "helper methods" that you don't actually need.

The Workflow:

Let the AI generate the feature.
Verify that it works.
Refactor and Delete.

Go through the generated code and ask: "Do I really need this private method? Can I do this with a standard Rails helper?" Treat the AI-generated code like a rough draft. Your job is to edit it down until only the essential logic remains.

4. CSS and View Refactoring

Tailwind CSS is a superpower for deleting code. Before Tailwind, I had thousands of lines of custom CSS in application.css. I was terrified to delete any of it because I didn't know which page it styled.

With Tailwind, the style is in the HTML. When I delete a view partial, the CSS dies with it.

If you find yourself writing custom CSS classes like .user-profile-header-v2, stop. Convert it to pure Tailwind utility classes. This allows you to delete your .css files entirely and rely on the framework to keep your bundle size small.

5. The "Dead Code" Audit

Every few months, I run a "Dead Code" audit. I look for:

Unused Routes: Run rails routes and see if there are paths pointing to actions you deleted.
Unused Partials: Look in your views folders for files that aren't being rendered anywhere.
Abandoned Migrations: If you have 50 migrations that just add and remove the same column while you were experimenting, consider squashing them.

Summary

A "Majestic Monolith" is only majestic if it is clean. If it is filled with dead code and abandoned experiments, it’s just a "Big Ball of Mud."

The goal of the One-Person Framework is to give you the power of a team. But a single human cannot manage a 100,000-line codebase alone without burning out.

Keep your app small. Keep your Gemfile lean. And remember: The most satisfying feeling in programming isn't seeing a green test suite—it's seeing a Pull Request that says "-1,500 lines."

The Solo Developer's Secret: Why Boring Tech is More Profitable

The One-Man Framework — Wed, 20 May 2026 22:06:26 +0000

Every morning, I see the same thing on my Twitter feed or the GitHub Trending page. A new Ruby gem is released that promises to "revolutionize" how we handle state, or a new "minimalist" alternative to a standard Rails tool that has 500 stars in its first week.

As developers, we love new things. We love "cleaner" syntax and smaller dependencies. But after building and maintaining Rails apps for years, I’ve stopped chasing the hype.

In 2026, my Gemfile is intentionally boring. I prefer gems that have been around for a decade over the latest shiny trends. Here is why boring tech is actually a solo developer's greatest competitive advantage.

1. The "Abandoned Gem" Trap

When you use a brand-new gem that just trended on GitHub, you are taking a massive risk.

The maintainer might be excited today, but what happens in six months when they get a new job or lose interest in the project? If that gem breaks when Rails 8.1 comes out, you are the one who has to fix the source code or find a way to migrate away from it.

"Boring" gems like Devise, Sidekiq, or Kaminari have survived multiple Rails version upgrades. They have a team of maintainers and a massive community ensuring they don't die. For a solo developer, "stability" is a feature that is more important than "cool syntax."

2. AI and Documentation Edge

In the era of Vibe Coding and AI assistants like Cursor or ChatGPT, boring gems have a huge advantage: Training Data.

AI models have read millions of lines of code involving the "standard" gems.

If I ask an AI to "Add a password reset flow using Devise," it gets it right 100% of the time.
If I use a shiny new auth library released three months ago, the AI will hallucinate and give me broken code because it hasn't seen enough examples yet.

By using the most popular gems, you make your AI assistant 10x more effective. You can find the answer to any bug on StackOverflow in 30 seconds. With shiny new gems, you are the one writing the first StackOverflow question.

3. The "Standard" Rails Way (Omakase)

Rails is built on the idea of Convention over Configuration. When you stick to the "Boring" defaults, your app stays standard.

If I hire a freelancer or bring in a partner to help me with a project, they already know how Devise works. They already know how to check a Sidekiq queue. If I have replaced every standard tool with a "shiny" alternative, I have to spend three days teaching them my unique, custom stack.

4. Don't Waste Your "Innovation Tokens"

There is a great concept in engineering called Innovation Tokens. You only get a few of them for each project.

If you spend your tokens on a "revolutionary new way to handle database IDs" and a "bleeding-edge frontend reactive library," you have no tokens left to spend on the Actual Business Logic that makes your app unique.

I save my innovation for the features that my customers pay for. I don't want to innovate on "how to upload a file" or "how to paginate a list." I want those things to be as boring and invisible as possible.

Summary: My "Boring" Checklist

Before I add a new gem to my project, I check three things:

Age: Has it been maintained for at least 2 or 3 years?
Usage: Does it have millions of downloads on RubyGems?
Recent Activity: Was there a commit or a release in the last 6 months?

If the answer to any of these is "No," I usually stick to the standard Rails default, even if the new gem looks "fancier."

Boring gems allow you to focus on shipping products instead of fixing your tools. In the world of indie hacking, the developer who ships the most wins - and boring tech helps you ship.

Why "Good Enough" Design is the Solo Developer's Secret Weapon

The One-Man Framework — Tue, 19 May 2026 22:06:26 +0000

I spent years looking at websites like Stripe or Linear and feeling depressed. I would try to replicate their custom animations, their unique shadows, and their perfect color palettes. I would spend three days just trying to design a "Pricing" card in CSS, and by the time I was finished, I was too exhausted to actually write the billing code.

As a solo developer, your biggest enemy isn't a lack of talent - it's Perfectionism.

If you are a one-man team, you have to accept a hard truth: You do not have time to be a world-class designer. But here is the secret: You don't need to be. You just need "Good Enough" design to build a profitable business.

Here is how to use "Good Enough" design as your secret weapon to ship faster and make more money.

1. The 80/20 Rule: Whitespace and Typography

90% of professional design isn't about colors or logos; it’s about Spacing and Reading.

If you get these two things right, your app will look 80% better instantly.

Typography: Pick one clean sans-serif font (like Inter or system-ui) and stick to it. Don't use 4 different font sizes. Pick three: one for headings, one for body text, and one for small captions.
Whitespace: If something looks "clunky," you probably didn't give it enough room. Double your padding. Use p-8 instead of p-4.

The Result: A clean, readable interface that looks "intentional" rather than "accidental."

2. Stop Making "Design Decisions"

Every time you ask yourself, "What shade of blue should this button be?", you are wasting mental energy.

"Good Enough" designers don't make decisions; they steal them. I use Tailwind UI or DaisyUI because the design decisions have already been made by professionals.

<!-- Don't think about the shadow, the border-radius, or the hex code. -->
<!-- Just use the system. -->
<button class="bg-indigo-600 text-white rounded-lg px-4 py-2 shadow-sm">
  Save
</button>

When you follow a system, your app stays consistent. Consistency is what makes an app feel "premium," even if the layout is basic.

3. Dark Mode is a Luxury, Not a Requirement

I see so many solo devs spending their first week building a Dark Mode toggle.

Unless you are building a coding tool or a night-time reading app, your users do not care about dark mode on Day 1. They care if your app solves their problem.

Stick to a high-contrast Light Mode. It is easier to design, easier to debug, and works for everyone. You can add dark mode after you hit $1,000 in monthly revenue. Until then, it is a distraction.

4. Components are Your "Stencils"

In the previous articles, we talked about ViewComponent and Phlex. This is where "Good Enough" design really shines.

You build a "Primary Button" once. You make it look "Good Enough." Then, you never think about buttons again. You use that component for every single action in your app.

As a solo dev, you want to turn design into a solved problem. You want your views to be a simple assembly line where you just snap pre-made parts together.

5. Launching is the Best Design Tweak

A "perfect" design that stays in your ~/projects folder is worth zero dollars. An "ugly" design that is live and collecting credit cards is a business.

Once your app is live, your users will tell you what is actually wrong. Maybe the button is too small to click on mobile. Maybe the text is too light to read. These are the only design tweaks that matter.

"Good Enough" design is a weapon because it allows you to reach the feedback stage faster.

Summary

The goal of a solo developer is to reach Product-Market Fit, not to win a Design Award.

Use a system (Tailwind).
Focus on spacing (more whitespace is always better).
Use pre-built components (stop reinventing the modal).
Ignore the fancy stuff (no custom animations yet).

Spend your time on the Database and the Marketing. Let your design be "Good Enough" so you can finally hit the deploy button.

Why Rails 8 is the Only Choice for the Modern Solopreneur

The One-Man Framework — Mon, 18 May 2026 22:06:26 +0000

In the world of startups, there is a dangerous myth. People think that to build a "real" application, you need a team of five: a frontend expert, a backend specialist, a database admin, a DevOps engineer, and a designer.

If you follow this path as a solo developer, you will fail. You will spend all your time trying to glue different technologies together instead of talking to customers.

In 2026, the goal isn't to write the "fastest" code in terms of CPU cycles. The goal is Developer Velocity. You need a framework that handles the boring stuff so you can focus on the features.

After trying everything from Next.js to Go, I am convinced that Ruby on Rails 8 is the best framework for a one-man team. Here is why.

1. The Death of the "Infrastructure Tax"

For years, even a simple Rails app needed a lot of "extra" stuff to run in production. You needed Redis for background jobs, Redis for caching, and usually a Node.js server to compile your JavaScript.

Rails 8 has completely removed this "tax." With the Solid Trilogy, your entire stack is now just your app and your database (Postgres or SQLite).

Solid Queue: Your background jobs live in your DB. No Redis needed.
Solid Cache: Your HTML caching lives in your DB. No Redis needed.
Solid Cable: Your WebSockets live in your DB. No Redis needed.

For a solo dev, this is huge. It means your production server is simpler, cheaper, and much easier to debug.

2. No-Build Frontend (The Hotwire Revolution)

I used to spend half my day fighting with npm, webpack, and node_modules. It was exhausting.

Rails 8 uses Importmaps and Hotwire by default.

No Build Step: You save a file, refresh the browser, and it’s there. You don't need a heavy compilation process.
Turbo 8 Morphing: You get the speed of a React Single Page App (SPA) but you write 100% Ruby code. The browser is now smart enough to update the page without a full reload.

You can build a fast, reactive dashboard in an afternoon that would take a React developer a week to wire up.

3. Deployment is Solved (Kamal 2)

Deployment used to be the scariest part for solo developers. You either paid $100/month for a "managed" service like Heroku, or you spent days configuration Nginx and SSL on a raw Linux box.

Kamal 2 changed everything. It allows you to deploy a Dockerized Rails app to a $5 Hetzner or DigitalOcean VPS with one command:

kamal deploy

It handles the SSL certificates, the zero-downtime switching, and the health checks. You get the power of a private cloud for the price of a sandwich.

4. The "Editor-in-Chief" Workflow (AI Readiness)

As I’ve written before, we are in the era of Vibe Coding.

Because Rails is built on Convention over Configuration, it is the perfect partner for AI tools like Cursor or ChatGPT. Because every Rails app follows the same folder structure, the AI rarely makes mistakes.

If you tell an AI: "Add a billing system with a 'Pro' and 'Basic' plan," the AI knows exactly where the models, controllers, and views go. In a "flexible" framework like Express or FastAPI, the AI often gets lost. In Rails, it is a superpower.

Summary: The Math for the Solo Dev

As a one-man team, you have 40 hours a week.

Framework A (JS/Microservices): 20 hours on plumbing, 10 hours on CSS, 10 hours on features.
Rails 8: 2 hours on plumbing, 8 hours on CSS, 30 hours on features.

The choice is obvious. Rails 8 is the only framework that truly respects your time. It is designed to let one person build an empire.

Goodbye Nginx and Redis: Building a Zero-Service Monolith in Rails 8

The One-Man Framework — Mon, 18 May 2026 16:08:35 +0000

The "Zero-Service" Monolith: How to run your entire app on a single server port

For years, I believed that a professional Rails app needed a small army of services to survive in production. You couldn't just run Rails. You needed Nginx to handle SSL and assets, Redis to handle background jobs and caching, and maybe a separate load balancer.

As a solo developer, managing all these pieces is exhausting. Every new service is another thing that can crash, another version to update, and another port to secure.

With Rails 8, we are entering the era of the "Zero-Service" Monolith. The goal is simple: your entire application should live inside a single Docker container and communicate with the world through one single port. No Redis, no Nginx, no headaches.

Here is how to collapse your stack into a single, powerful unit.

STEP 1: The "Solid" Trilogy (Deleting Redis)

In the past, Redis was mandatory for two things: background jobs (Sidekiq) and caching.

Rails 8 replaces Redis with the "Solid" gems. These tools use your existing database (Postgres, MySQL, or SQLite) to do the work that Redis used to do.

Solid Queue: Handles your background jobs.
Solid Cache: Handles your HTML fragment caching.
Solid Cable: Handles your real-time WebSockets.

By switching to these, you can literally uninstall Redis from your server. Your background jobs now have the same "ACID" guarantees as your data, and you have one less service to monitor.

STEP 2: Thruster (Deleting Nginx)

Puma (the Rails web server) is great at running Ruby, but it isn't great at serving images or handling SSL certificates. That is why we always put Nginx in front of it.

Rails 8 includes a new tool called Thruster. It is a tiny, incredibly fast proxy written in Go that wraps around your Rails app.

Thruster handles:

HTTP/2: Speeds up loading for your users.
SSL (HTTPS): It manages your Let's Encrypt certificates automatically.
Asset Compression: It Gzips your CSS and JS files so they download faster.

Because Thruster is bundled into the Rails Docker image, you don't need to install or configure Nginx on your server anymore. You just point your domain to the container, and Thruster handles the rest.

STEP 3: The Single-Port Configuration

When you use Kamal 2 to deploy your Rails 8 app, it packages everything into one container.

In your deploy.yml, you no longer have to define "Sidecars" for Nginx or link to a Redis container. You just define your web server.

# config/deploy.yml
service: my-app
image: yourname/my-app

servers:
  web:
    - 123.45.67.89

proxy:
  ssl: true
  host: myapp.com
  # Everything enters through port 80/443 and goes straight 
  # to Thruster inside the container.

When this container starts up, it boots Thruster, which boots Puma, which starts the background job workers. Every part of your app is now living in the same memory space, on the same timeline.

STEP 4: SQLite for the Win (Optional)

If you want to go for the "Ultimate Zero-Service" setup for a micro-SaaS or a side project, you can even skip the external Database server by using SQLite.

With the recent improvements in Rails 8, SQLite is production-ready for many use cases. If you use SQLite, your "database" is just a file inside your container. Combined with Litestream for backups, your entire "Cloud Empire" is now literally just one single Docker process running on a $5 VPS.

Why this is a game changer for you

Mental Bandwidth: You only have to think about one thing. Is the container running? If yes, the whole app is working.
Cheaper Hosting: You don't need a server with 16GB of RAM to run 5 different services. A small, cheap server is plenty.
Faster Onboarding: When you hire a freelancer or use an AI to help you, they don't have to spend two hours setting up a complex local environment. They just run the app.

Summary

The "Zero-Service" Monolith isn't about being lazy; it's about being efficient. As a solo developer, every minute you spend configuring a Redis config file is a minute you aren't building features for your customers.

Rails 8 and Kamal 2 have made it possible to own your infrastructure without being a DevOps expert. One container, one port, one successful business.