Jason Fried's Blog

June 18, 2013

About two years ago, The Starter League set out to teach absolute beginners how to code. Since then, they’ve expanded their offerings to include HTML, CSS, and design.




To date they’ve graduated over 600 students from all over the world. A true success story on so many levels.




One thing they’ve noticed along the way is that their best students return back to take additional classes in different disciplines. They may start learning Rails, but then they want to learn advanced HTML/CSS. And then they want to learn visual design.




Further, these students seem to want more than just the independent skills – they want the whole integrated package. They want to know how to build a product and turn that product into a sustainable company.




Announcing Starter School: A truly unique program

So today The Starter League announces their newest — and most ambitious — initiative: Starter School.




Starter School is an intense, full-time, 9 month program. It’s basically the grad school for people who want to learn how to build software and start companies. It’s small and hands on: there are only slots for 52 students. This way every student can get the attention they deserve.




They’ve lined up an outstanding roster of teachers, and put together a thorough, full-time, 9-month program where you’ll learn everything you need to know to build the back-end, design the front end, and bring your product to market. It’s the most well-rounded curriculum I’ve seen yet.




A few folks from 37signals will be teaching. Ryan Singer will be teaching product design. Mig Reyes will be teaching visual design. I’ll be dropping in to teach a few things, too.




Tuition for the 9 month program is $36,000. The inaugural class will get $3000 off. To help, I’ll also be providing partial scholarships for three highly motivated, sharp students. Other scholarships will be available too. Details will be provided after you submit an application.




If you want to learn the whole stack – programming, design, and business – from some of the best, don’t delay. This is a one-of-a-kind program. Apply to Starter School today or just find out more.




Disclosure: 37signals is an investor in The Starter League.



0 comments
Twitter_icon  • 
Published on June 18, 2013 13:43

June 17, 2013

Today our first five customers started using Know Your Company, our newest product. We’re hoping to roll out around five new customers every Monday for the foreseeable future.




I thought this was a great time to talk a bit about how we’re building Know Your Company. Not the tech, specifically, but the approach.




From the start, I wanted to approach the development of Know Your Company as if we were starting a separate company inside 37signals, not just building another product at 37signals.




So I went back to 2003. That’s when we originally built Basecamp. Basecamp was basically a new business inside 37signals. I looked back at how we did it.




We had a small team of four – two designers (me and Ryan), one programmer (David), and one person who could help with a variety of things (Matt). We were building something to scratch our own specific itch.




We didn’t have much tech to lean on. We didn’t have Rails, we didn’t have a centralized billing system, we didn’t have a centralized log-in system, we didn’t have much experience launching a product with a new business model (subscription pricing), we didn’t have a server farm (we just had a shared server slice on another company’s machine), etc.




Basically, a lot was very new to us, and the newness was invigorating. It allowed us to approach problems objectively rather than fitting our problems into solutions we’d already built before. Think of it more as a bespoke suit than something off the rack.




Basecamp was a bespoke suit, but just about everything we’ve done since then has been trying to fit into Basecamp’s clothes in one way or another.




I wanted to get away from that way of thinking with Know Your Company. It’s just too easy to continue to lean on the things you’ve done, the decisions you’ve made, and the infrastructure you’ve already built.




So here’s what we’re doing.




We’re starting with a small team of four. Me and Jonas on design. Trevor on programming. And Dan as the multipurpose jack-of-all-trades. I’m also doing sales/demos, which is something we’ve never really done before.




Further, just like when we launched Basecamp, I did all the customer support for the first year or so. That’s what I’ll be doing with Know Your Company too.




As for billing, we’re not using Queenbee, our centralized billing system that powers Basecamp, Highrise, Backpack, Campfire, and a variety of other things we sell. Instead, we’re building a bespoke billing system from scratch. Just what we need, nothing we don’t.




This way we don’t have to compromise a business model approach because our billing system is only set up to do things one way. If we have a different idea for how we want to bill customers (or accept payments), I don’t want to be hamstrung by old decisions. I want to have the freedom to make new decisions.




Queenbee also has a bunch of admin tools built in so we could comp accounts, change ownership of an account, look up a customer and update their information, etc. We’ve left that all behind with Know Your Company. Know Your Company has its own custom admin built right into the product. This way we can build specific admin tools to onboard new customers, update accounts, generate invoices, and everything else that’s unique to Know Your Company.




Another thing we’re doing differently this time around is sales and setup. Our default position when building new products is to make them self-service, just like Basecamp’s been since day one. No interaction with us is required to sign up. Just click a button, pick a plan, sign up, and you’re off and running.




That model has obviously been very successful for us. No question about that. But let’s learn something new. Let’s get a feel for what the opposite approach is like. What if we were full-service instead of self-service? What if we were very hands-on, rather than completely hands-off?




So that’s what we’re doing with Know Your Company. There’s no self-service sign-up. If you want to use Know Your Company, we have to give you a personal demo first. Want to sign up? We’ll walk you through it step-by-step. We’ll even load up your employees for you so you don’t have to do any work. And we’ll also populate your account with a specific set of questions so you don’t have to think about what to ask your employees if you aren’t sure what to ask.




Isn’t full-service harder, more time consuming? Yes it is. And wow it’s been worth it. I’m getting to have a nice conversation with every customer we have. I’m getting to learn a lot about their companies, their struggles, and their goals. This is very healthy for us. The product is going to be way better for it – especially in the long-term.




The business model is all new, too. Instead of defaulting to our Basecamp-famous monthly subscription fee, we’re treating Know Your Company more as a one-time investment in each employee rather than an ongoing recurring expense. So instead of charging a monthly/annual fee, we’re just charging $100 per employee one-time. Once you’ve paid $100 for an employee, you never have to pay for them again. You can use Know Your Company with them for as long as they work for you.




Now, we’re not entirely free from the past. There are still a few things we’re leaning on because they aren’t hampering our flexibility.




For one, we’re using 37id – our centralized sign-in system. Know Your Company customers can sign in with the same username/password they use for their Basecamp accounts. That’s easier for them than having to sign up with another username/password.




We’re also using Rails, which we didn’t have the luxury to use when we built Basecamp. And we’re leaning on our sophisticated server infrastructure and the things we’ve learned about email, too. But the load we’re putting on the system is barely a pimple so I don’t feel so bad about that.




And of course we have the reputation and trust build up behind 37signals over the last 14 years.




But as far as our development approach goes, this feels the closest to the feeling we had when we were building Basecamp nearly 10 years ago. Lots of new things, lots of new approaches, a feeling that we can build whatever we need rather than fitting new ideas into old decisions.




If you’re interested in becoming a customer, please review the introduction letter I wrote. If it resonates with you, and you fit the profile, drop me an email and I’d love to show you around and maybe even get you started.



0 comments
Twitter_icon  • 
Published on June 17, 2013 13:10 • 8 views

Steve Jobs: The Most Important Thing (via Farnam Street). A simple reminder that each of us has the ability to shape life into whatever we can dream up.



0 comments
Twitter_icon  • 
Published on June 17, 2013 12:23 • 7 views

June 14, 2013

The first exception should be the hardest one to make. Once you’ve made one, each additional exception gets exponentially easier. Beware that first exception.



0 comments
Twitter_icon  • 
Published on June 14, 2013 10:18 • 10 views

June 13, 2013

As we watched Apple unveil iOS7, the 37signals Campfire room quickly turned to awe of what they had achieved. A redesign so shocking and deep bestowed upon a product so popular left many mouths agape. Whether you happened to like the final product wasn’t as relevant as marveling at the vision, drive, and sheer determination to pull it off.




Apple has a way of making people feel like that.




But what followed next is at least as interesting: We all sought to explain just how they did it. Is it all Ive’s eye? Is it that they explore more ideas than anyone else? Is it never accepting “good enough”? Forgoing customer input and trusting their own instinct? Hundreds of triple-A designers and developers?




There were lots of suggestions. But stepping back a meter or two, it was clear that we all simply reached for our own grandest ambitions and rebranded them Apple’s secret sauce. Theorizing why Apple is able to do what it does is an organizational Rorschach.




That doesn’t make it a useless exercise. Au contraire. It just makes it more about you than them. It lets you tease out your goals and aspirations for your own work and process. It’s a kick in the ass to marvel at greatness and think of reasons “why are we not as awesome as that?”.




An organization as rich and storied as Apple has a thousand reasons for why it got to where it is. Pinning it on any one answer is futile, but it’s sure to spark a healthy debate. Indulge.



0 comments
Twitter_icon  • 
Published on June 13, 2013 07:09 • 8 views

Rails ships with a default configuration for the three most common environments that all applications need: test, development, and production. That’s a great start, and for smaller apps, probably enough too. But for Basecamp, we have another three:





Beta: For testing feature branches on real production data. We often run feature branches on one of our five beta servers for weeks at the time to evaluate them while placing the finishing touches. By running the beta environment against the production database, we get to use the feature as part of our own daily use of Basecamp. That’s the only reliable way to determine if something is genuinely useful in the long term, not just cool in the short term.
Staging: This environment runs virtually identical to production, but on a backup of the production database. This is where we test features that require database migrations and time those migrations against real data sizes, so we know how to roll them out once ready to go.
Rollout: When a feature is ready to go live, we first launch it to 10% of all Basecamp accounts in the rollout environment. This will catch any issues with production data from other accounts than our own without subjecting the whole customer base to a bug.

These environments all get a file in config/environments/ and they’re all based off the production defaults.



So we have something like this for config/environments/beta.rb:




# Based on production defaults
require Rails.root.join("config/environments/production")

beta_host_name = `hostname -s`.chomp[-1]

BCX::Application.configure do
# Beta namespace is different, but uses the same servers
config.cache_store = :mem_cache_store, PRODUCTION_MEM_CACHE_SERVERS,
{ timeout: 1, namespace: "bcx-beta#{beta_host_name}" }

# Each beta server gets its own asset environment
config.action_controller.asset_host = config.action_mailer.asset_host =
"https://b#{beta_host_name}-assets.bas..."
end

This gives each beta server its own memcache namespace and asset compilation, so we can run different feature branches concurrently without having them trample over each other.




Since many of our associated services are shared between production and the beta/staging/rollout environments, we take advantage of the YML reference feature to avoid duplication:




production: &production
url: "http://10.0.0.1:9200"
beta:
<<: *production
rollout:
<<: *production
staging:
url: "http://10.0.1.2:9200"


Custom Configuration

To run six environments like we do, you can’t just rely on Rails.env.production? checks scattered all over your code base and plugins. It’s a terrible anti-pattern that’s akin to checking the class of an object for branching, rather than letting it quack like a duck. The solution is to expose configuration points that can be set via the environment configuration files.




Lots of plugins do this already, like config.trashed.statsd.host, but sometimes you need a configuration point for something existing in your code base or for a plugin that wasn’t designed this way. For that purpose, we’ve been using a tiny plugin called Custom Configuration. It allow you to do configuration points like this:




# Use cleversafe for file storage
config.x.cleversafe.enabled = true

# Use S3 for off-site file storage
config.x.s3.enabled = true

It simply exposes config.x and allows you to set any key for a namespace and then any key/value pair within that. Now you can set your configuration point in the main environment configuration files and pull that data off inside your application code. Or use a initializer to configure a plugin that didn’t follow this style.



In-app stage switcher

For 37signals employees, we expose a convenient in-app stage switcher to jump between the different environments and setups. That’s mighty useful when you want to checkout a new feature branch or ensure that everything got rolled out right.



Rollout to 10%

While the rollout servers are always ready, we only use them when a feature is about to go live. The process is to deploy the feature branch you’re about to merge to master to the rollout environment. Then you flip the switch with cap rollout tenpercent:enable, which instructs the load balancers to send 10% of accounts to the rollout servers. When you’re content that all is well with the feature branch, you merge it into master, deploy to production, and turn off the rollout again with cap rollout tenpercent:disable.




The great thing about doing it like this is that the enable/disable action is very fast. It’s not like the scramble to do a full capistrano rollback. This just ticks the load balancer to send some traffic or not. So the second you catch an issue, you can get the 10% back on regular production, fix the problem, and then try again. Great for your blood pressure levels!



Just do it

For a long time, all we had was the staging environment. But the addition of multiple, dedicated beta servers to test feature branches concurrently, and the rollout environment to deploy with more confidence, has been a big boost to our workflow. There’s not a lot of work in setting this up and Rails was built for it from the beginning. The defaults are just a starting point.



0 comments
Twitter_icon  • 
Published on June 13, 2013 05:58 • 9 views

June 11, 2013

For a long time I’ve felt like the only thing worth working on is the next most important thing. Why spend time working on something that’s less important if there’s something more important that needs work?




I’ve changed my mind on this. I think it’s always good to be working on two things: The next most important thing, and the next most interesting thing.




It’s hard for an interesting thing to compete for your attention if your only criteria for attention is criticality. Interesting things are rarely critical. They’re exploratory. And if you only think in terms of what absolutely needs your attention right now, you’ll never leave room for things that might satisfy your curiosity. That’s important too, just on a different level.




It’s in this spirit that I hope we have the courage to be more experimental at 37signals. Experimental design, experimental tech, experimental business models, experimental strategies, experimental experiments that may lead to brand new insights and outcomes we didn’t know we were capable of before.




I’m looking forward to the surprises.



0 comments
Twitter_icon  • 
Published on June 11, 2013 12:07 • 9 views

For a long time I’ve felt like the only thing worth working on is the next most important thing. Why spend time working on something that’s less important if there’s something more important that needs work?




I’ve changed my mind on this. I think it’s always good to be working on two things: The next most important thing, and the next most interesting thing.




It’s hard for an interesting thing to compete for your attention if your only criteria for attention is criticality. Interesting things are rarely critical. They’re exploratory. And if you only think in terms of what absolutely needs your attention right now, you’ll never leave room for things that might satisfy your curiosity. That’s important too, just on a different level.




It’s in this spirit that I hope we have the courage to be more experimental at 37signals. Experimental design, experimental tech, experimental business models, experimental strategies, experimental experiments that may lead to brand new insights and outcomes we didn’t know we were capable of before.




I’m looking forward to the surprises.



0 comments
Twitter_icon  • 
Published on June 11, 2013 12:07 • 11 views

Hi everyone—my name is Dan Kim, and I’m incredibly honored to introduce myself as the 37th signal! I joined the team on June 3, and I’ll be helping to build a brand new product, Know Your Company.




Ever since I started using Basecamp in 2007, I’ve admired 37signals. Like many of you, I’ve followed their work closely. I’d nod my head in agreement as I read SvN posts, watched videos, or read their books. They’ve consistently valued simplicity over complexity, thinking instead of talking, shipping over planning, and working remotely instead of commuting. It soon became my dream to work at 37signals.




It certainly wasn’t easy trying to make my dream come true. I had applied for positions a couple times before, but my skills didn’t match up well. Even though I have a decade of experience in web development and programming, I was rusty. Over the years I had transformed from a programmer to a manager. I couldn’t build from scratch anymore. I couldn’t ship anything by myself. That scared the living hell out of me, and so I needed to make a change.




And that’s when I discovered The Starter League. It’s a three-month, in-person program that teaches beginners how to design, program, and ship web apps, right here in Chicago.




I’m a recent grad myself, and it’s changed my life. I enjoyed it so much, I stuck around as a teaching assistant to help mentor others. And my work there helped me strike up a conversation with Jason, which led to a couple lunches, sharing some ideas, a successful trial project, and officially being hired.




But like many others, my career has had its ups and downs. I’ve seen the inner-workings of a wide variety of companies. Some were as big as 45,000 and others as small as 2. I’ve seen the good and bad of every possible company culture—startups, agencies, consulting, corporate, you name it. So it’s hard to express how happy I am right now to be surrounded by an amazing culture, learning from some of the best designers and programmers in the world.




And I’m thankful for all of it. Each experience has helped me realize and respect how important a person’s work can be to their happiness. That’s why I’m so excited to work on Know Your Company. We want to help small business owners build and sustain great companies that people love working at. That’s an incredible mission and challenge that I can’t wait to explore.




On a personal note, I live out in Chicago’s Northwest Suburbs, so I’ll spend some of my time in the office hanging out with these awesome folks. The rest of the time I’ll be working remotely at home, where I can annoy my incredibly patient wife Julie, watch our twin boys Andrew and Jonas grow up, and walk our super cool dog Parker.




Finally, and most importantly, I want to send a big, heartfelt “Thank You” to all of my friends, family, and colleagues who have helped me to get here. I couldn’t have done this without you.


All the best,


Dan



0 comments
Twitter_icon  • 
Published on June 11, 2013 09:24 • 4 views

Hi everyone—my name is Dan Kim, and I’m incredibly honored to introduce myself as the 37th signal! I joined the team on June 3, and I’ll be helping to build a brand new product, Know Your Company.




Ever since I started using Basecamp in 2007, I’ve admired 37signals. Like many of you, I’ve followed their work closely. I’d nod my head in agreement as I read SvN posts, watched videos, or read their books. They’ve consistently valued simplicity over complexity, thinking instead of talking, shipping over planning, and working remotely instead of commuting. It soon became my dream to work at 37signals.




It certainly wasn’t easy trying to make my dream come true. I had applied for positions a couple times before, but my skills didn’t match up well. Even though I have a decade of experience in web development and programming, I was rusty. Over the years I had transformed from a programmer to a manager. I couldn’t build from scratch anymore. I couldn’t ship anything by myself. That scared the living hell out of me, and so I needed to make a change.




And that’s when I discovered The Starter League. It’s a three-month, in-person program that teaches beginners how to design, program, and ship web apps, right here in Chicago.




I’m a recent grad myself, and it’s changed my life. I enjoyed it so much, I stuck around as a teaching assistant to help mentor others. And my work there helped me strike up a conversation with Jason, which led to a couple lunches, sharing some ideas, a successful trial project, and officially being hired.




But like many others, my career has had its ups and downs. I’ve seen the inner-workings of a wide variety of companies. Some were as big as 45,000 and others as small as 2. I’ve seen the good and bad of every possible company culture—startups, agencies, consulting, corporate, you name it. So it’s hard to express how happy I am right now to be surrounded by an amazing culture, learning from some of the best designers and programmers in the world.




And I’m thankful for all of it. Each experience has helped me realize and respect how important a person’s work can be to their happiness. That’s why I’m so excited to work on Know Your Company. We want to help small business owners build and sustain great companies that people love working at. That’s an incredible mission and challenge that I can’t wait to explore.




On a personal note, I live out in Chicago’s Northwest Suburbs, so I’ll spend some of my time in the office hanging out with these awesome folks. The rest of the time I’ll be working remotely at home, where I can annoy my incredibly patient wife Julie, watch our twin boys Andrew and Jonas grow up, and walk our super cool dog Parker.




Finally, and most importantly, I want to send a big, heartfelt “Thank You” to all of my friends, family, and colleagues who have helped me to get here. I couldn’t have done this without you.


All the best,


Dan



0 comments
Twitter_icon  • 
Published on June 11, 2013 09:24 • 8 views

Jason Fried's Blog

Jason Fried
Jason Fried isn't a Goodreads Author (yet), but he does have a blog, so here are some recent posts imported from his feed.
Follow Jason Fried's blog with rss.