The One-Person Framework in practice

In early 2022, when we counted our ARR at PlanGo, my co-founder and I shared a moment that we couldn't believe. We just crossed the magical €1M ARR milestone, something that felt unreal for a company built on one Rails codebase and one developer (me).

Let me be clear: I was not alone in building the business. My co-founder was very important for shaping our vision, meeting potential customers, and making growth happen. Our small support team made sure our customers stayed happy and successful. But on the technical side, it was just me: a Rails developer who was the architect, designer, full-stack engineer, database admin, and DevOps engineer all rolled into one.

When DHH talks about the "One Person Framework", he describes how Rails was built to enable a single developer to build and maintain a complete application. Rails was designed so that one person could handle everything: from database design to business logic to frontend UI. That isn't just hypothetical: I lived this.

This post is for the Rails developers who wonder if it's still possible to build something big without a team of specialists. It's for the technical founders who feel too much pressure from wearing many hats. And it's for anyone who believes in craftsmanship and using the right tools and frameworks.

I'll share the technical decisions that made our growth possible, the challenges of scaling both the application and the business, and the lessons learned along the way. Because while Rails promises a path "from HELLO WORLD to IPO", I find the journey in between far more fascinating.

In 2011, I was a 21 year old developer who thought he knew what he was doing. I had built some PHP applications with CodeIgniter, and switching to Rails seemed like the cool thing to do at that time. I had no big strategy, I just liked the idea of trying something new that everyone was talking about.

To kickstart PlanGo, my co-founder had this brilliant marketing idea: offer our software completely free for the first year to anyone who signed up during launch week. We expected maybe a few dozen curious users would take us up on the offer.

Our phones wouldn't stop ringing. Our inbox was flooding with questions from customers trying to understand our software, requesting features, and needing help. The problem wasn't that our server was struggling or that the application wasn't working, it was that I had built little more than an MVP, and now had 500 people expecting a fully-featured product with proper support.

We were completely overwhelmed. We had to disappoint many of those early customers because we simply weren't ready for that many users. Our part-time operation (both my co-founder and I had other jobs) was drowning in customer requests while I was trying to build out features that people were asking for.

It was a brutal but necessary lesson in the difference between building software and running a software business.

I need to be completely honest here: I had no idea what I was doing. Sure, I could follow Rails tutorials and Stack Overflow answers, but building a production application that people's businesses relied on? That was a different beast entirely.

My early Rails code was full of bad practices:

Every rookie mistake you can imagine, I made it. The application worked (somehow), but it was held together with duct tape and wishful thinking.

And then there were the gems. So. Many. Gems.

Need user authentication? Gem. File uploads? Gem. PDF generation? Gem. Admin interface? Gem. Email processing? Gem.

My Gemfile grew faster than our customer base. Each gem seemed like a shortcut at first, but soon created its own set of problems. One time I learned the (very) hard way that calling .round(2) on a number doesn't round to two decimals, but changes the rounding method to "banker's rounding”. At least, that's what happens when you rely on a Rails gem for handling money instead of just BigDecimal and basic arithmetic.

By 2013, as we were slowly figuring out how to actually run the business part, the technical debt was growing fast. It became increasingly harder to build new features. 

Every experienced developer knows: never do a full rewrite. It's considered the nuclear option: dangerous, time-consuming, and unnecessary.

In 2014, I broke that rule. With a few years of Rails experience, I made the decision to start fresh with Rails 4.

The rewrite took a couple of intense months, during which I maintained the existing application while building its replacement. This time, I approached development with more wisdom and dramatically simplified the architecture. I cut our gem dependencies by more than half and wrote tests for critical functionality.

The new codebase was simpler, faster, and (most importantly) maintainable by a single part-time developer. This rebuilt foundation would become critical for what came next: growing a business where I was the only developer for over a decade.

People often don't believe me when I tell them I was the only developer at PlanGo until 2025. "How is that even possible?" they ask. The simple answer: Rails.

Rails kept me fast and efficient. Convention over configuration, integrated testing, ActiveRecord, ActiveStorage, and ActiveJob eliminated decisions that didn't matter, allowing me to focus on building value. When Turbolinks and later Hotwire came along, I could build modern UIs without worrying about the newest, flashiest JS framework of the day. 

When I initially started building PlanGo in 2011, mobile apps weren't really a thing yet. Our customers didn't expect us to build a mobile version beyond some responsive overviews. This changed dramatically over the years. Now our native iOS and Android apps have become the primary way people interact with PlanGo.

Getting to this point wasn't straightforward. I experimented with frameworks like Titanium and RubyMotion, and even learned some Objective-C to build native apps. Each approach came with significant trade-offs between quality and development speed. 

Then came Turbo Native. It was an unbelievable level-up in productivity. I learned just enough native development to be dangerous: how to structure an app, handle authentication, and implement native-feeling transitions. Turbo filled in the rest, allowing me to leverage my existing Rails codebase and skills.

For many business-oriented apps, especially in B2B or SaaS, this approach is the holy grail: native performance and feel, with a fraction of the development effort. The proof is in the numbers, our apps combined have over 100.000 yearly downloads (we even briefly passed Duolingo in the Netherlands!), all built and maintained by one Rails developer.

Some numbers so you can get an idea of what we're working with:

Sticking with a well-structured monolith was one of my best decisions. No microservice headaches, dead-simple Capistrano deployments, easy debugging. All crucial when you're a one-person show.

For technical founders, Rails isn't just another framework; it's a way to do the work of an entire team by yourself. It’s a superpower.

Around the end of 2022, something unexpected happened. A foreign investor approached us, interested in PlanGo. By that time, we'd grown beyond €1M ARR, all bootstrapped and profitable. No outside funding, no massive team, just a lean operation powered by Rails.

This potential acquisition made us pause and reflect: What did we actually want? We had built a successful business on our own terms. Did we want to sell? Scale aggressively? Keep things exactly as they were?

It was time to think about our future in a way we hadn't before. We explored various options, talked to different investors, and did some soul-searching. What became clear was that we loved our business but saw opportunities that would be easier to pursue with additional resources and expertise.

And let's be honest, after years of building something valuable, taking money off the table isn’t a bad reason to consider investment. We'd put our time and energy into PlanGo for over a decade. Realizing part of that value while still growing the business just made sense.

Eventually, we found a perfect middle path: a Dutch evergreen fund that aligned with our values and long-term thinking. We sold a portion of PlanGo to them, maintaining significant ownership and control while gaining partners who could help us reach the next level.

This wasn't about a quick exit or scaling at all costs. Instead, we found partners who understood the value of what we'd built: a sustainable, profitable business with happy customers. We wanted to build on that foundation rather than disrupt it.

Now we're continuing our journey together, focused on the same Rails-powered approach that got us here, but with additional resources to pursue opportunities we couldn't before. 

After 14 years of building PlanGo as a solo technical founder, I've learned a few lessons that might help other Rails developers on similar journeys:

Fighting the framework creates unnecessary friction. The "Rails Way" exists for a reason. It allows you to focus on what makes your product unique, not reinventing solved problems.

Every gem (and JS library) adds complexity and potential points of failure. I've learned to ask "Do I really need this?" before adding anything to my Gemfile.

As a solo developer, staying connected to other Rails developers is crucial. Building Spina CMS gave me a community that didn't replace having colleagues, but provided a valuable second-best for sharing ideas and learning.

Sometimes the pragmatic solution that gets you to market faster is the right one, even if it's not technically perfect. Just be intentional about when you take on debt and when you pay it down.

With Rails, a single developer can build, scale and deploy a product that would normally require an entire team of developers. Don't let conventional wisdom about "needing a team" hold you back.

Our new partners, while fans of our lean approach, had one non-negotiable requirement: adding another Rails developer to the team. The challenge wasn't about wanting to remain solo; it was about onboarding someone to a codebase that had evolved alongside my own development as a programmer over 14 years.

The code represented not just PlanGo's evolution, but my own journey from a beginner to a more experienced developer. Parts of the codebase contained decisions made by different versions of myself, with varying levels of experience and understanding. Having someone else step into the twists and turns of my brain across 14 years of code was a daunting prospect.

Despite these challenges, bringing on our second Rails developer (who I met at Rails World in Canada!) has been transformative. Not only has it reduced the pressure of being the single point of failure, but it's brought fresh perspectives and ideas I wouldn't have considered. Pair programming sessions have improved our code quality, and having someone who speaks the same Rails language has been intellectually rewarding.

Looking ahead, we're not planning to build a massive engineering team. Our Rails-powered approach has proven that you don't need armies of developers to build valuable, scalable software. But I've learned that even the most efficient solo developer can benefit from the right teammate.

PlanGo's story is an example of how Rails as a One-Person Framework works. It's proof that with the right tools tiny teams can build serious businesses on their own terms. Whether you're a solo developer building your first product or a small team considering your tech stack, I hope my journey shows what's possible when you use Rails to its full potential.

Working solo in Rails? Shoot me a message, I’d love to hear what you’re building.