It breaks my heart to read Tom Howard’s post on his struggles with his startup.

On many levels, I can relate to his story.  When Stephen and I started Archon a few years ago, we had no money and no funding.  We mostly muddled through our first two/three years with minimum-wage projects, Stephen’s scholarship fund, and my grandmother’s pension savings.  I still remember vividly of being afraid to attend gatherings with friends, seeing them making decent programmers money, and feeling like a failure when asked what was I up to.

But I’m not going to talk about all those struggles in this post.  I think most startup entrepreneurs will share the same “just-suck-it-up-and-keep-rolling” mentality.

What I want to write about is the current trend in startup as I see it, and a reminder that we should get back to the basic.

My partner, Stephen, had a brilliant observation on the recent craziness we see in the startup world:

“It’s not just the startup world.  Interest rates are low, gold prices are high, stocks and bonds aren’t yielding that well … in general because of demographic and other trends, there are too many people wanting to lend (and earn interest) and not enough people productively borrowing.  So it’s only natural that this spills over into the startup world.

I don’t see a major “correction” in the next decade.  The age of easy, predictable return on investments is over.  Lots of startups overvalued?  Yes.  Bubble?  No.”

To extend his thoughts, I think a multiple of factors have yielded the vibrant startup craze we see today:

1. Big successes on seemingly simple apps: Twitter, Draw Something, Dropbox, Instagram, etc.
2. Access to funds with just a PowerPoint deck, or a weekend-all-nighters prototype, or “my friend’s friend just got funded by doing …”
3. Coding up something usable is quick and easy-to-learn with technologies such as Ruby on Rails, Django, Cake php, etc.
4. You only need a few people – most of the time two to three only.
5. Financial cost of doing a startup is low, and most people are willing to stay lean at the beginning.
6. The idea of “if I solve this little problem/pain-point that so many people have, then I can make millions.  Look at Company X.  If things don’t work, I will just pivot.”  Keyword here is little.

The optimism is good and all.  Without it, we, as a society, won’t be able to take awesome photos, sync them across computers, and tweet them for the world to see.  Without it, we, as programmers, will all just be stuck at our bank jobs, wearing a tie and wondering why we haven’t hung ourselves with it yet.  Without it, we, as founders, will sleep even less at nights.

But realistically, most startups will fail.

When my older brother found his first startup, it was a bit before the dot-com bubble, back in the 90s.  They were well-funded, had a talented team, and a beautiful office space.  Heck, they even gave me my first internship!

But the problem was that they weren’t really making money.  They were building websites for other companies, doing cool little projects here and there, and generally just having fun.  When the dot-com busted, funding stopped, and they had to close shop.  It was very disheartening for me to learn the news, as I always thought my brother was invincible.

Lesson that I toke from his experience was: “a company has to make money”.

Zooming back to today, I think startups nowadays had learned from their predecessors, somewhat.  Hey, at least they didn’t have the whole Lean Startup and YC thing back then, right?

But I think the basic human psychology is still at play here.  As Warren Buffet said:

“… when your neighbor has made a lot of money by buying internet stocks, and your wife says that you’re smarter than he is and he’s richer than you are, so why aren’t you doing it.”

Similarly, some might think: “if Twitter didn’t bother thinking about monetizing in its early days and is still super successful now, then why should we think about monetizing that early?  Better to find the product/market fit first and build some traction from it.”

In my observation, quite a bit of startups are still going with this line of thinking.

Don’t get me wrong.  I think it’s perfectly fine to use investor’s money for developing the product before its launch.  And it is perfectly fine to live on investor’s money for a bit until things are picking up.

But what doesn’t sit well with me are startups with no real plans to make money on day one, and are just hoping the ill-thought-out freemium or half-baked ad-supported models will save their day, once they get enough users.    The key here is, of course, once they get enough users.

I think instead of wishing for the ideal case, people should first look at the baseline.  We should work backwards and ask: “how much money per month does it take for us to keep the team alive, so that we can all keep on working?”

After that, just do a simple math of calculating the average revenue per paying users, the number of paying users you need, the conversation rate within the industry, and, finally, how many active users you need per month to make all these numbers.  Once you have all these numbers, ask yourself honestly in the mirror: “Can I realistically make these numbers before the money burns out?”

All these might sound like common sense, and I’m sure it has been covered extensively in many other books/articles.  But with the recent string of big acquisitions and seemingly over-night successes, I just want to remind us that we should all focus on the basic first: “the company has to make money”.

We are looking for another awesome web app programmer to join our dev team on the *secret stealth project*!

If you think you have some serious front-end chops (HTML/CSS/JS) and had done some Ruby on Rails code before, then join us on the fun!

For more details, take a look at the position on our career page.

Woohoo, after like 2 months of hard work, the WiX Burn installer (which I talked about in the previous post) is finally launched on our website at www.inflowinventory.com/Download, as well as www.download.com!

Check out the installer to get a taste of what WiX Burn can do! I think most can agree that the our new installer has a much better user experience

Lets say, you wanted to store contact information such as emails, phone numbers, and websites. These contact information can be associated with an employee of a business or the business itself. A business can have multiple emails and multiple phone numbers. Similarly, an employee can have multiple emails and multiple phone numbers. In Rails, we can store all these contact information in a single table using both the polymorphic association and single-table inheritance. First, lets see how we can use polymorphic association to deal with the contact information.

We have the following active record models for a “Business” and an “Employee”:

class Business < ActiveRecord::Base; end
class Employee < ActiveRecord::Base; end

For the contact information, we have the following active record models:

class Email < ActiveRecord::Base; end
class PhoneNumber < ActiveRecord::Base; end
class Website < ActiveRecord::Base; end

Now, for the associations, Business and Employee models can have many emails, phone numbers and websites. And conversely, Email/Phone Number/Website can belong to either a Business model or an Employee model. How do we make up the association?

Rails ActiveRecord provides an association called “Polymorphic” association. Using polymorphic association, a model can belong to more than one other model, on a single association. Here is how this can be implemented:

class Business < ActiveRecord::Base
has_many :emails, :as => :emailable
has_many :phone_numbers, :as => phonable
has_many :websites, :as => webable
end

class Employee < ActiveRecord::Base
has_many :emails, :as => :emailable
has_many :phone_numbers, :as => phonable
has_many :websites, :as => webable
end

class Email < ActiveRecord::Base
belongs_to :emailable, :polymorphic => true
end
class PhoneNumber < ActiveRecord::Base
belongs_to :phonable, :polymorphic => true
end
class Website < ActiveRecord::Base
belongs_to :webable, :polymorphic => true
end

Having the above setup, you can get a collection of emails for a business instance via the call “@business.emails”. Similarly, you can get a collection of emails for an employee instance via “@employee.emails”.

Now, if you really think about what a contact information is? It basically contains a label and an information. I.e. Personal Email: test@gmail.com, Business Phone Number: 1-800-999-9999, Business Website: www.google.com, etc.

So, we can say that an email, a phone number, or a website is an instance of a contact information class with two attributes: a label and an information. Thus, we can store any type of contact information in a single table.

In rails, if you name a column “type”, by default ActiveRecord allows inheritance by storing the name of the class in the column type. You can overwrite the Base.inheritance_column to change the name of the column where the class name is stored. Now, changing our polymorphic associations as “contactable”, we can have the following setup:

class Business < ActiveRecord::Base
has_many :emails, :as => :contactable, :class_name => "Email"
has_many :phone_numbers, :as => :contactable, :class_name => "PhoneNumber"
has_many :websites, :as => :contactable, :class_name => "Website"
end
class Employee < ActiveRecord::Base
has_many :emails, :as => :contactable, :class_name => "Email"
has_many :phone_numbers, :as => :contactable, :class_name => "PhoneNumber"
has_many :websites, :as => :contactable, :class_name => "Website"
end

class ContactInformation < ActiveRecord::Base
belongs_to :contactable, :polymorphic => true
end
class Email < ContactInformation
# any validation for email can go here
end
class PhoneNumber < ContactInformation
# any validation for phone numbers can go here
end
class Website < ContactInformation
# any validation for website urls can go here
end

All the emails, phone numbers and websites will now be stored in the table associated with the model “ContactInformation” and will have the following setup:

create_table :contact_informations, :force => true do |t|
t.string "contactable_type"
t.integer "contactable_id"
t.string "type"
t.string "label"
t.string "info"
t.timestamps
end

Now, when you create a business email:

@email = @business.build.emails(:label => "Personal", :info => "test@gmail.com");
@email.save!

the record will be saved in the table “contact_informations” with the values “Business” for the “contactable_type”, @business.id for the “contactable_id”, and “Email” for the column “type”.

Similarly, for employee phone number:

@phone = @employee.build.phone_numbers(:label => "Work", :info => "1-800-123-4567");
@phone.save!

the record will be saved in the table “contact_informations” with the values “Employee” for the “contactable_type”, @employee.id for the “contactable_id”, and “PhoneNumber” for the column “type”.

Rails makes it really easy to do a single table inheritance with polymorphic association.

So about a month and a half ago, I was driving home from work one day after working on some NSIS installer code (which in my humble opinion is very ugly and hard to work with), when I had the thought “How come no one uses managed code to write installers?”. Managed code is so much cleaner to read, and the .NET framework is so powerful. Most of the time we’re just copying files, writing registries, and running some msiexec anyways right? nothing managed code can’t handle.

So I did a little bit of googling and then found this amazing new beta release of WiX 3.6. In the beta release there is a new bootstrapper/downloader module named Burn which allows you to chain multiple MSIs together (something WiX was lacking for a very long time), download packages online, and use managed code to create the bootstrapper interface. After reading about the features here and trying out the Visual Studios 11 Preview installer, I was pretty convinced to give it a shot.

After using Burn for a while, I can say that there are some clear advantages with using managed code to write a bootstrapper. The first advantage is that it allows you to streamline your interface in so many different ways… for example, you don’t have to create a page where you “accept the license agreements” anymore, since most people don’t read that anyways. It also lets you create an experience where the novice users can simply click an install button, without having to select all the customization options.

Another advantage is that you can use all the features of Windows Forms and WPF to create your interface. So this allows you to use all types of different controls and animations to create a much better looking user interface.

There are disadvantages of using a managed bootstrapper though, because it requires that the user has the .NET framework installed on their computer. Thankfully, Burn also handles that for you. When Burn fails to run the managed bootstrapper, it will run a separate bootstrapper to install the .NET framework first. Following that, it will run your own installer.

Some more disadvantages of using Burn right now, is that there is almost no documentation, and that there are still some bugs in the framework. In terms of the documentation, you really have to be prepared to do a lot of googling to find the answers that you’re looking for. Sometimes, I had to dig through the open source C++ code to get a better understanding of how the Burn engine works.

For those that want to give the toolset a try, here are some tips that I think will be helpful:
1) Read http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx
2) Download the WiX source and take a look at the project stored in “wix36-sources\src\Setup\UX”. It contains the managed code that was used to create the WiX installer
3) Dig through http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ when you need to find answers