I was recently inspired by a blog post from the founder of PlanGo. His story of generating approximately $1.5 million in annual revenue as a solo developer rekindled my appreciation for the potential of the Rails framework.

The PlanGo Case: Succeeding as a Solo Developer

The founder of PlanGo managed all Rails development on his own for over a decade, eventually reaching an ARR of €1 million (about $1.5 million). He described Rails not merely as a framework, but as a “superpower that allows one person to handle the work of an entire team.”

His key success factors included:

  • Embracing Rails conventions to avoid wasting energy on unimportant decisions
  • Maintaining a well-structured monolithic architecture
  • Minimizing unnecessary libraries and tools
  • Managing technical debt strategically
  • Building efficient mobile apps using Turbo Native

His story proves that with the right tools and approach, a solo developer can build a business of significant scale.

Surviving as a Rails Developer in Large-Scale Korean Companies

I began my career as a backend engineer using Ruby on Rails at a major Korean IT company. Since then, I’ve developed Rails-based services at various companies and even experienced an IPO. But my challenges were quite different from those faced by PlanGo.

The projects I worked on weren’t monolithic systems. During the rise of microservice architecture (MSA), various teams were being formed, and the original monolith was gradually being broken apart.

One of the biggest differences was hiring. Finding Ruby on Rails developers in Korea was extremely difficult. The usual approach was to hire engineers who would learn Rails after joining. Reading the PlanGo story made me wonder: Was expanding the team really the best approach, given the Rails philosophy? With Rails’ strengths, perhaps we could have achieved our goals with a smaller team.

Rails’ Advantages and the Korean Ecosystem Reality

Having used Rails for years, I believe its biggest strength is rapid development. It enables tight feedback loops for validating and iterating on business logic. However, when used only as an API server, you can’t fully take advantage of those strengths.

In Korea, Ruby on Rails hasn’t become a mainstream framework. Java and Kotlin — both JVM-based — dominate the enterprise space, which is evident from the frequency of meetups, conference talks, and job postings. This has limited the growth of the local Rails ecosystem.

The Importance of Non-Technical Partners

As the PlanGo founder noted, doing everything alone is tough. No matter how business-savvy a developer may be, you still need a partner who can articulate the vision, engage with users, and set direction without being limited by technical constraints.

For technical founders, Rails is a powerful tool — but business success depends on more than technology. In PlanGo’s case, the co-founder played a crucial role in shaping the vision and driving growth.

Could I Do It Too? PlanGo’s Message of Hope

What resonated most with me was the realization that Rails remains a powerful and practical option for solo developers. For senior developers aiming to start their own business, PlanGo’s story is a strong source of motivation.

While large organizations require complex systems and teams, the “one-person framework” philosophy of Rails is still highly relevant for solo founders and small startups. It offers a competitive edge in the early stages of building and scaling a product.

Conclusion: Pursuing a Dream with Rails

As a Rails developer, I feel more confident about the future after reading PlanGo’s story. Although Korea’s tech culture and ecosystem may differ, this reinforced my belief that it’s possible to build a meaningful business with Rails.

If you’ve worked with large-scale systems and teams, that experience can be even more valuable when you go solo. By combining Rails’ speed and simplicity with business insight, we can build PlanGo-like success stories here in Korea too.

Having grown through complexity, I’m now drawn to the idea that I can create something meaningful on my own. After all, sometimes, less is more.