This time I wanted it to be my idea. I started thinking about the problems I had in my life: I have a (relatively) long commute to work, my email and calendar apps are a sort of shoddy, makeshift to-do system, I’m horrible at remembering names, dates, and other miscellaneous facts, I fairly frequently find myself with a table of data and dreading using MS Excel to make a chart out of it, etc. I took a half-hour out of my day a few times and started listing the small annoyances in my life. Pretty soon I had a good list of possible projects.

Much like last time I took my list and axed things that I had little interest in or things that required skills I didn’t have and didn’t want to learn. That narrowed down my list into things that I wanted to work on and could reasonably execute on. However, I’d been through this idea listing process before and ultimately I ended up choosing a business idea that wasn’t right for me. Somewhere in the process of choosing a project from that filtered list I’d made a mistake.

I realized that the criteria I had used to choose a project last time hadn’t been very effective. I needed something new; something that would help me find a business idea I’d be more successful with. Thinking through the mistakes of last time I came up with four criteria to help me choose a new project:

• Excitement (Low/Medium/High): This is an indication how excited I am to work on the project. Any project with a low excitement level I immediately throw out. And a “medium” is a bit of a warning sign for me. It basically means that my interest in the project could start to tail off after a while, so if I don’t think I’ll be able to execute on the idea quickly I shouldn’t consider the project.
• Complexity (Low/Medium/High): This indicates a couple things: technical difficulty and scope of the project. It gives me some indication of how quickly I could execute on a project. I decided that a project with medium excitement and high complexity should be abandoned as I wouldn’t be able to complete the project by the time I would lose interest in it.
• Dog food (Yes/No): This shows whether I personally would use the application or not (i.e. eat my own dog food). I think more than anything this is a requirement if you don’t have more than one founder. When you’re on your own you need to have a crystal clear vision of the problem and solution.*You don’t have a co-founder to bounce ideas off of and steer you back in the right direction if you get off course. If I have a project marked with a No, I toss it.
• Non-Ad Revenue (Yes/No): This indicates whether or not the project has a viable revenue stream other than advertising. It’s not a requirement for a project, but it is a requirement for a business. In other words, if this column has a “no” I relegate it to being a hobby project that likely has no prospects for going any further than that. There’s nothing wrong with hobby projects, you just need to be aware that that’s what it is.

I created a table with five columns, one column for the project name plus four columns for the criterion above and rated every project (one added bonus to using personal problems as business ideas is that all of the potential projects are “dog food projects”). After filtering out projects that were advertising-only, projects that had low excitement, and projects with medium excitement and high complexity, I was left with one idea that seemed viable.

*Note that there is an excellent chance that your solution is wrong and your users will be quick to tell you as much. Their advice is useful, don’t ignore it. Just make sure that there is always a clear vision for your product, even if that vision changes. Heading in too many directions at once is a sure-fire way to fail.

Next time: Market Analysis

So with these red flags in the back of my mind I thought about what the larger problem was. The first issue is that I wasn’t passionate about the idea. There are some major problems with current dating sites and lots of room for improvement. But at the end of the day working to improve dating wasn’t something that excited me. At least not to to the point that I wanted to work on it day after day for months on end. Strike one.

The second issue was that I would never be one of the end-users of my application (note the “my wedding” part above). Again, not necessarily an issue if you have a good grasp of the problem and you’re in touch with lots of would-be users of your application. However, I wasn’t in touch with lots of would-be users, and I wasn’t particularly motivated to go out and meet a bunch more. Strike two.

The third issue is that I hadn’t done my due diligence in solidifying a solid revenue stream other than advertising. There’s nothing wrong with having advertising as your main source of income, but advertising is generally a lot more effective when you already have a decent membership base using your website. I was starting with zero users. Meaning the only way to monetize the site would be to rapidly build a user base. Strike three.

With all of that in mind I decided that it was no longer a good idea to pursue scotchel.com. It was a hard decision but it ultimately feels right. It is a lot better to fail now than to invest increasingly larger amounts of time on the project and fail later. It is always better to fail fast.

Next time: Evaluating Business Ideas

For anyone that is considering getting married in the future, I have to say that eloping* is definitely the way to go. You only have to worry about yourselves and that makes everything ridiculously easier. There’s only two people to please instead of 100+. In that same vein I wish we’d done something simpler for the reception. Our dinner, while fantastic, would have been much less stress-inducing with a simple buffet or cocktail party. And if you have a child or children, leave them with the grandparents (or hire a sitter) the evening before and the day of your wedding/reception. The two of you will have enough to worry about without your kids running around demanding your attention.

In an upcoming post I’ll talk about the future of scotchel.com and where I’m headed next.

*I just looked up elope and the one of the first definitions is to run off secretly to get married, usually without the consent of one’s parents. To be clear, we did have the consent of our parents. I wonder if there’s a similar word that is with consent. And not secretly.

Simple, right? I sure wasn’t going to go reinvent the wheel by writing my own CSS for them though. Thankfully after searching for a bit I came across SimpleBits’ Mini Tabs. I didn’t want mini-tabs, but the HTML and CSS was remarkably clean. Only 4 CSS declarations on a simple HTML list with a class=”active” for the current tab. With some modification to the CSS I was able to come up with tabs that looked like the above (even looks good in IE7, amazingly).

So, if you want some decent looking/functioning tabs go yank the HTML/CSS from the above link.

I hadn’t updated my blog in more than a week and as I mentioned a while back blogging is one of the ways I keep myself motivated. Thus, not updating my blog is a red flag to myself. Thankfully I’ve made a fair bit of progress lately. I took a few hours on Saturday and hammered on the site at an undisclosed location (makes me wish Jailbreak Omaha were around… (it’s the end of summer guys, where are you?! ). They were the most productive hours I can remember in recent history, and I plan to do it again.
Progress wise I’m almost back to where I was before I switched from PHP to Ruby on Rails. It’s hard to tell if I’m quicker in RoR than I am in PHP because I’m reusing a lot of the logic/decisions from the first time, but if I had to take a guess I’m say I’m moving quicker. I’m definitely writing a lot less code and things just seem to make more sense. I can see where CodeIgniter was pulling concepts from Rails (and they do a good job of it), but the PHP/CodeIgniter combination seems a lot more clunky than Ruby/Rails.

Anyway, given another weekend or so I think I’ll have completed everything I had in PHP and will be moving on to new and better things. Next up on the docket is building the view and edit profile pages which should be fairly straightforward (*knock on wood*).

An October release looms close; I’m not sure I’ll make it with the time lost switching to Rails, but I still think it was ultimately the right decision to switch. RoR has been much more enjoyable to program in. I write less code yet accomplish more. Plugging in various bits of code is a breeze. It makes me wish I’d taken a look at RoR a few years ago.

Let’s get an example registration app set up:

rails registration
ruby script/plugin install http://svn.techno-weenie.net/projects/plugins/restful_authentication
ruby script/generate authenticated user sessions

Cool, now you have your registration app set up with a Users model, controller, and view. If you start up your server and head to http://localhost:3000/users/new/ you should see a very basic registration form. Let’s add our Address model. For the sake of brevity, I’m just going to create a field that references the User model and one field for a zip code, but you get the idea.

ruby script/generate model Address user:references zipcode:string
rake db:migrate

With our Address model in place, we need to let the User model know that it is linked to the Address model. Here’s what the User model looks like (\app\models\user.rb):

1
2
3
4
5
6
7

require 'digest/sha1'
class User < ActiveRecord::Base
  # Virtual attribute for the unencrypted password
  attr_accessor :password
 
  validates_presence_of     :login, :email
  # lots more stuff that we're not going to worry about...

We’re going to add three things:

1
2
3
4
5
6
7
8
9
10
11

require 'digest/sha1'
class User < ActiveRecord::Base
  has_one :address
  accepts_nested_attributes_for :address
  attr_accessible :address_attributes
 
  # Virtual attribute for the unencrypted password
  attr_accessor :password
 
  validates_presence_of     :login, :email
  # lots more stuff that we're not going to worry about...

We’ve told the User model that (1) it has one Address model, (2) that it should save data for Address automagically, and (3) that the address_attributes fields are permitted fields to receive data for (if you read through the code a bit further you’ll see another attr_accessible line, you could add address_attributes there too).

We need to make one change to the User controller (\controllers\users_controller.rb) to prevent an “Called id for nil” error later on. At line 6 you should have an empty new method. We’re going to create an instance variable for User:

6
7
8
9

  # render new.rhtml
  def new
    @user = User.new
  end

Let’s now take a look at the one User view that restful_auth created (\app\views\users\new.html.erb):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<%= error_messages_for :user %>
<% form_for :user, :url => users_path do |f| -%>
<p><label for="login">Login</label><br/>
<%= f.text_field :login %></p>
 
<p><label for="email">Email</label><br/>
<%= f.text_field :email %></p>
 
<p><label for="password">Password</label><br/>
<%= f.password_field :password %></p>
 
<p><label for="password_confirmation">Confirm Password</label><br/>
<%= f.password_field :password_confirmation %></p>
 
<p><%= submit_tag 'Sign up' %></p>
<% end -%>

First of all, we need to change the form_for :user to be form_for @user. Second, we get to add in our zipcode field:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<%= error_messages_for :user %>
<% form_for @user, :url => users_path do |f| -%>
<p><label for="login">Login</label><br/>
<%= f.text_field :login %></p>
 
<p><label for="email">Email</label><br/>
<%= f.text_field :email %></p>
 
<p><label for="password">Password</label><br/>
<%= f.password_field :password %></p>
 
<p><label for="password_confirmation">Confirm Password</label><br/>
<%= f.password_field :password_confirmation %></p>
 
<% @user.build_address unless @user.address %>
<% f.fields_for :address do |a| %>
  <p>
    <%= a.label :zipcode %>
    <%= a.text_field :zipcode %>
  </p>
<% end %>
 
<p><%= submit_tag 'Sign up' %></p>
<% end -%>

Here’s where I ran into the two gotcha’s. If you don’t switch form_for :user to form_for @user when you submit the form you’ll get a very unpleasant error that looks like this:

ActiveRecord::AssociationTypeMismatch in UsersController#create
Address(#46729050) expected, got HashWithIndifferentAccess(#23561230)

Second, if you don’t add in line 15, @user.build_address unless @user.address, you’ll get the following error when you try to view the form:

You have a nil object when you didn't expect it!

More info on why that error occurs here.

Anyway, with the above steps you should now have a registration form that creates records for both User and Address. If you found this helpful, leave a comment and let me know!

So, without further ado, here are the mockups:

First view profile mockup

Second view profile mockup

Edit account mockup

Edit profile mockup

Whenever I was watching more TV than working on my Great Idea, it was because I was stuck. I didn’t realize it at the time, but my mind was avoiding making a tough decision or working through a particularly hard problem. My Internal FUD pushed me towards easier tasks. Watching TV was a whole lot easier than spending a couple hours researching, thinking about, and making the tough call. –7 lies that prevent your great idea from becoming a real business

Whenever I find myself not working on my project I come back to this quote, because it’s always true. Anytime I’m not working on scotchel.com for any significant amount of time it’s because I’ve hit a roadblock. My current issue can be stated simply: do I continue building the site in PHP or do I switch over to Ruby on Rails?

The answer has been hard to come by, perhaps because I haven’t really sat down to think about it. But I was tired of being “stuck” so I spent an hour this morning reviewing why I might want to (or not want to) switch to Ruby. And, as of now, I’m going to make the switch to Ruby. I’ll try to get to the same place I left off in PHP (at the very least) and we’ll see how it goes. From what I’ve read, it should be both easier and more fun, so I’m looking forward to it.