Two weeks ago [my team] had an idea. Today, we made money on it.

I’m super proud of how fast this went.

I know so many sites that spend over a year even in pre-beta, I don’t understand why.

Here’s how we did it.

Skip beta

We spent zero time in beta. We basically just setup the production site, then developed on that until we were ready to send out marketing e-mails. Because of this, we spent no time moving everything to a production site and getting it configured.

Skip developers

We have two part time developers who work about 5-40 hours a week. Both of us have full time commitments, me as a college student and the other as a full-time software engineer.

I actually like it this way, at least for now. Having fewer developers means that there are only two people to keep updated on all the code, and since we’ve been working together for nearly a year, we don’t have to spend anytime dealing with all of the issues that arise with large teams or with new developers.

Skip unit tests

Our site has zero unit tests. Instead we have about 250 cucumber steps. We used cucumber and machinist to quickly drive out features with the entire team (4 people total). Drawing from our experience with switching to rspec stories then Cucumber when it came out, we found that unit tests simply become a burden when we’re in an environment that is changing so fast, and when everything is already covered with cucumber and easy to test b/c we are using cucumber for bdd.

If I have to update a unit test every time I change something, plus I have to update a cucumber feature every time I change something, it quickly becomes a waste of time. Instead, we just test the hell of of the interface with cucumber. Our coverage, according to RCov, is around 95%. We use hoptoad, which lets us know that we have yet to have a production bug.

Of course, as things get more complex (hopefully v. slowly), it will absolutely be necessary to have unit tests for certain model methods, however at the moment it’s simply not necessary. We just run autotest while developing, plus mandate that no tests fail before committing.

To test e-mail we used, Ben/Arron/My lovely gem email-spec.

Skip writing code

We skipped writing at least a thousand lines of code by using plugins and gems to do it for us.
Our controllers are pretty much all under 10 lines. Most are around 5. To do this we use resources_controller, response_for and reponse_for_rc, which handles basic crud code, plus basic custom responses.

We skipped writing tons of authorization code. While restful_authentication is a great plugin, and was certainly outstanding when it was released, it requires maintaing the huge “lib/authenticated_system.rb” plus a ton of code in your user model. We used Authlogic instead, which let us write only a few lines of authorization stuff. In addition, password reset took minutes rather than hours to setup because of this.

We skipped writing tons of fixtures by using machinist.

We skipped writing tons of asset management code by using Thoughtbot’s paperclip instead of attachment_fu.

Most importantly, we skipped writing tons of hokus pokus code by doing things inline. A lot of rails developers seem so focused on DRY that the put all kinds of bullshit constants in their environments files, make all kinds of bullshit one use partials that they end up never using again, and all kinds of other bs that they just don’t need. By skipping all that hokus pokus, it’s always immediately obvious to us what is happening where, and what we need to change to make something work.

We also used a somewhat simpler way of doing css and views, by designing first and by writing some simple block helpers to deal with the elements that show up on every page. Possibly another post on that later.

Skip features

The list of features that didn’t make it in is so much longer than the list of features that did. We realized that we basically only needed a few features in order to launch.

By using pivotal tracker for quite a while, we know how much the team can do in a week, so by ordering the stories in terms of preference, it was always immediately clear if something had to be cut.

The key here was really the fact that the team has been together for quite a while. Everyone understands that development is not just “feature → done” and that cutting features lets us polish the ones we choose to implement.

This is the key part of the 80/20 rule: 80/20 shouldn’t mean you implement 100% of the features and do 80% of everything for them, it means you implement 80% of the bare minimum of things that need to happen for the site to launch, and then make sure you did a sick job with those features. 37s’s products have tons of little polish everywhere, they are not doing 80% when they make the page scroll down automatically when you click a button, they are polishing the hell out of the 80% that they chose to do.

Skip deployment haze

We recently switched from joyent to slicehost, after I found on some outside projects that it is miles easier. This meant that we also switched from mongrel to passenger and ruby enterprise. It literally took me 10 minutes from saying “I’m going to setup deployment” to having the site live and running.

Not to knock joyent, though. It’s partially b/c I have much more experience with ubuntu than with solaris.

Make it easy to the point of obviousness

Taking everything that we learned from our main product, we realized that we just don’t want to make people think at all when using our site. When we designed the interface (we obviously skipped photoshop and all the rounded corner hell that goes with designers that use it), we focused on making all of the things that you can do contextual and so obvious that it college coaches and athletes would spend zero time thinking about our site, and all their time solving what matters to them.

Pro Marketing

The other 2 people on the team are both from the a business school. As a group, we spend tons of time figuring out how to market our products.

So, while our process is obviously far from perfect, and the site has a long way to go, it’s a great feeling to go from a meeting where someone says “I think we should make a site for x because it’s too hard and we can make it easier” to $$$ in what feels like no time at all.

Like this post? Check out another startup-related post I wrote called Mind the gaps.

Note: too busy to fix openid atm, so please just use your name if you want to comment.

Update

While I got some flak for doing no unit testing so far in the comments, it looks like Hashrocket is doing something similar:

From the Rails biz listhost:

"
So I just took a walk around the office and did an informal survey.
Two of our projects are using Cucumber. The first is still doing BDD
with RSpec for the whole stack: models, controllers and views. I
don’t find this particular approach too interesting because it’s what
I consider a traditional approach. Their Cucumber is used purely for
integration testing.

The other team is doing BDD with Cucumber and “dropping down” to
write RSpec specs only for non-basic business logic in models and a
few controllers. I spent close to two weeks coding full-time on that
team and I can tell you from personal experience that it was a joy to
BDD at a high-level. That said, our Cucumber steps include checks for
rendering and redirection and also view content — in other words,
full coverage is still maintained.

The rest of the teams just haven’t had a chance to jump on the
Cucumber bandwagon yet, but I’m guessing most of them will do so
sometime soon. All of them do full-coverage BDD with RSpec.

Cheers,
Obie
"