Stop Building for Everyone, Start Building for Your Mom

Last month, my sister asked me why her Ubuntu desktop kept freezing. It's a question I've heard variations of at least a hundred times—from family, from friends who heard I "know computers," from people at parties who corner me near the snacks. My instinct was always the same: open a terminal, run diagnostics, explain what swap memory is, watch their eyes glaze over.

But here's what actually happened: I spent three hours troubleshooting, realized the real problem was just a cluttered home directory, fixed it, and then she called me again two weeks later with a different panic. That's when I realized I wasn't solving the problem—I was just being tech support on-call.

That moment stuck with me when I read about someone building a Rofi-based AI assistant specifically because their mom couldn't figure out Linux. Not because they wanted to ship a product. Not because they were chasing some SaaS dream. But because they were tired of being interrupted, and they built something practical to solve their actual life problem.

The Elegance of Using What's Already There

The thing that impressed me most about this approach isn't the AI integration—it's the decision to build on Rofi instead of starting from scratch with something like Eww or Electron. As developers, we have this terrible habit of reaching for the newest, flashiest tool when a mature, proven alternative would work just fine.

Rofi is a launcher. It's fast. It's lightweight. It's already sitting on the desktop. Adding an AI layer on top of it means you're not bloating the system with another background daemon or Chromium instance. You're extending something that's already there.

That's production thinking right there. Not "what would be cool to build," but "what can I actually maintain on my system without it becoming a tax on my CPU and my sanity?"

Building for a Real User You Actually Know

The genius move here is making something for a specific, real person with a specific, real need. Not an abstract "Linux newcomer," but mom specifically. That constraint forces you to make actual tradeoffs instead of feature-creeping forever.

I think about this with my own work constantly. When I build something that's "for users," it tends to meander. When I build something specific—like a dashboard for our internal team that I'll see every day—it's ruthlessly focused. Pain points jump out immediately. Features that looked good in theory get cut because I hate using them.

The post mentions they kept adding things until it felt "complete"—localization, dark mode, natural voices, better UX polish. These aren't flashy. They're invisible when they work. But they're the difference between a tool someone uses daily and a tool that collects dust.

Where I'd Think Differently

I respect the philosophy here, but I'd have one concern if I were building this myself: maintenance burden. An AI-powered assistant that works well today might break tomorrow when APIs change or the underlying models shift. For my mom, stability matters more than features.

I'd probably build it with multiple backends—fallback to a simpler rule-based system if the AI service goes down. Maybe cache responses locally. Basically, I'd architect it the way you'd architect anything your non-technical family member depends on: defensively.

Also, I'm curious about the localization aspect. If your mom uses your language and you're shipping this open-source, you're inviting a whole maintenance nightmare of translations. I wonder how they handle that in practice.

The Real Lesson

What got me is that this isn't a think piece about AI or Linux or UX. It's about a developer solving a real problem in their life, refusing to overcomplicate it, and then sharing the work. No grand vision. Just: my mom needs help, I can code, I built a tool, here it is on GitHub.

We don't do enough of that. We spend too much time debating architectures and chasing performance metrics that don't matter. A working solution for one person is better than a perfect solution for no one.

Your Turn

Are you built tools specifically to solve your own problems, or do you usually aim for something more broadly useful? I'm genuinely curious whether the "build for your own life first" approach leads to better software, or if it's just survivor bias because the successful projects get shared.

Source: This post was inspired by "I built a Rofi assistant so my mom could stop calling me for Linux help" by Dev.to. Read the original article