It started with a simple manifesto. A manifesto posted online with 37 guiding principles, small phrases showcasing big ideas like “We See People” and “Not Full Service” and “We Don’t Throw Curves.” The website was a list of rules for a web design agency to follow, created by Jason Fried, Carlos Segura, and Ernest Kim as they were creating an agency of their own. They decided to name their company 37signals (after the number of unidentified radio signals in the air), and used their own manifesto as an ideological starting point.

From the beginning, 37signals tried to stand out by not standing out. At at time when other agencies promised to do it all, sometimes haphazardly bolted on to an already behemoth advertising firm, 37signals took a more focused and direct approach. For one thing, they were just web designers. No print, no ads, just websites. It was a line few others had drawn in the sand, but shifted their focus to smaller clients with smaller needs and simple solutions.

They were also pretty good. Their client list grew, bolstered by the word of mouth and referrals that have become the backbone of agency leads on the web. Even as the web came crashing down around them in the wake of the dot-com bubble, 37signals kept their agency bootstraped (and proud of it), focusing on small wins, and slow but deliberate growth. Employees at 37signals, however, did find one marketing tactic particularly appealing: sharing what they know. Their blogging was prolific, and in the years to come, essential.

By 2003, 37signals had run into a challenging, yet somehow reassuring issue with their client list. It was too long. Communication between the company and their clients was beginning to breakdown, and lists of emails, file attachments, and calendars just weren’t cutting it. So one of their developers, David Heinemeier Hansson, began working on an internal tool to help them manage that list. A single place where contacts, communication and client feedback could be stored. Since Hansson was building the thing from scratch, he could chose any programming language to be his brick and mortar. He chose Ruby.

Ruby dates all the way back to 1995, when it was first created by Yukihiro Matsumoto (sometimes referred to as just “Matz”). Matsumoto had been talking to a friend about the limitations of Perl and Python, two other languages which became major influences for Ruby, and the issues he was running into time and time again. Ruby more or less manifested from this conversation, a language meant to address these drawbacks in a neat, focused, and easy to follow package.

Matsumoto’s philosophy permeates through every decision made about Ruby’s design, fundamentally that a developer should never be surprised. He made the language dynamically typed so it could be flexible, borrowed syntax from Perl so it was concise, and mirrored Python’s object-oriented  construction so it was organized. Matsumoto honed in on the needs of developers, and with Ruby, tried to check them all off.

Originally, Ruby’s documentation was only in Japanese, so the language didn’t spread too far beyond Japan’s borders. But in the early 2000’s, Matsumoto created and English site and mailing list, and Ruby became a tool of choice for a number of developers.

Hansson really liked Ruby. In many ways, it echoed the principles at the foundation of 37Signals, mirroring in code what the agency had made plain for clients. Their signal We See People mapped right on to Ruby’s focus on developers and no-nonsense productivity, Simplicity By Design almost a perfect match for Ruby’s principle of least surprise. Java and PHP might have had some of the same features, but they lacked a compatible philosophy, the former far too rigid and the latter too malleable.

Hansson spent part of his day, each day, toiling away with Ruby building out the new internal tool. It wasn’t long, however, before pieces of his new application revealed themselves as useful and reusable. If his app needed, say a router or an easy way to connect to a database, it was reasonable enough to assume that there must be others facing the same problem. As Hansson describes it, he felt almost an obligation, no doubt infused in him during his time with 37signals, to share his work with the larger web community. He began picking apart his code so he could bundle it together in a single package. The project became Basecamp. The code became Ruby on Rails.

Ruby on Rails because it was meant to make web development as frictionless as possible. Officially released in early 2005, it came bundled with tools for web developers, like routing, database access, and views and templating. It emerged as a natural extension of the Ruby language, with a focus on developer’s needs and developer happiness.

Monolithic by design and exhaustive in nature, Hansson took Ruby’s commitment to developer’s expectations and manifested from it an idea he called convention over configuration. The idea being that there were hundreds of little decisions developers had to make every day, but a good amount of them bordered on the arbitrary, and could be made upfront, with no specific knowledge of the project. So Rails made a lot of decisions for developers, like how to organize code, and which templating system to use, setting smart defaults along the way. What was lost in flexibility, the argument went, was made up for in productivity.

That philosophy paid off. By the time version 2 of the software came out in 2007, it was hitting wider and wider adoption, even shipping by default in Apple computers.

Throughout the development of Ruby on Rails and Basecamp, 37signals kept their client work. That left them without a ton of overhead and unable to pay for any advertising or a massive pivot or change in business model. Instead, they reached back to their core competency and once again shared what they knew. Hansson created a video demo, sometimes referred to as the “whoops” demo, where he built a blog using Rails in just 15 minutes.At just about each step, Hansson would showcase what was missing from his app, and then whoops – yes, he literally said this – it would work with just a few lines of code. A demo video might not feel like a big deal, but it was not really done at the time. Most frameworks surfaced some dry API docs and maybe a splash page. But Rails tossed their video up next to detailed documentation and in-depth blog posts.

As Rails grew, Basecamp grew (and vise versa) as they entered into a symbiotic relationship. Rails generating more users for Basecamp who heard of the product in the developer community, and Basecamp serving as an always-on example of what Rails could do. It worked because they were both grounded in the same underlying ideology, that happiness was the key to a successful product, whether that product lived in code or on the screen, and that sharing was not only essential, but an obligation.

Meanwhile, Basecamp did just fine. It creeped up over 100,000 users by 2006, when 37signals decided to stop taking new client work, and focus solely on Basecamp (and a few related products). Just last year, 37signals announced that they were changing their name to simply Basecamp, and doubling down on the platform. They have millions of accounts.

Ruby on Rails has had contributions from almost 5,000 developers, now up to version 5. Each release has been a step forward, with some mild controversy along the way. But the Rails doctrine remains intact. Programmer happiness first. Everything else second.