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

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:

1. Let the AI generate the feature.
2. Verify that it works.
3. 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."