Lo-Glo as You Go
Globalizing and localizing a Rails app isn’t hard work, but it’s mind-numbingly tedious if you have to do it all at once. Trust me. You’ll be happier if you lo-glo as you go, so just do it if there is the slightest possibility you’ll need to later on. REST Along the Way
I’m not talking about naps (never been a fan of those). I’m talking about how you structure your controllers and views. If you don’t understand REST at the beginning of your project, just take a little time to learn it. I wish I had. Now, every time I touch something that’s not RESTful, I re-factor it. I lourve the cleanliness, but I wish I’d just done it this way from the very beginning. Even the mistakes I would have made would be easier to clean up now if I’d used REST. Get Crazy about Plugins: Don’t re-invent the garbage truck, let alone the wheel. It’s sometimes surprising what has already been done for you, from authentication to calendars, there are Rails plugins galore. Watch the Freakin’ RailsCasts: I was about a year into TroopTrack before I watched my first RailsCast by Ryan Bates. This is one of the best Rails resources on the web and will open your mind to a lot of stoof you wouldn’t think of on your own. When in Doubt, Pick the Rails Way: Let’s say you had a choice between using cascade deletes at the DB level and using :dependent => :destroy in the model. You might be tempted by cascade deletes, depending on your back-story as a coder. Don’t do it. GO WITH THE RAILS WAY. Later on, when you’ve been around the block a few dozen times, you might feel comfortable with deviating from the Rails way, but … try the Rails way first.
A Goal to Dream On
How do you think a company should set it’s growth goals for a SaaS product prior to its launch? What do you think those goals should be? What criteria might you use to figure it out? Would you look at market size, price point, competition market share, etc?
When I was daydreaming about TroopTrack.com, I did exactly that. After a while, I came up with a goal that was basically enough customers to make $500,000 in revenue after 2 years. Pretty reasonable right?
Wrong
The problem with this sort of goal is that I didn’t have a clue what I was doing. I wasn’t even in the market yet, and here I was prognosticating 2 years into the future.
And I call myself an agilist.
I should be ashamed.
A Series of Goals
Goals should grow incrementally, starting with the first attainable goal, and you should really only work on one goal at a time, the immediate next goal. That way, you can adjust future goals based on what you learn form working on your current goal.
A Goal to Start With
The very first goal you should have is to get a customer. One. This can be harder than you think, but whether you convince someone to pay real money for your product on the same day you launch or the six months later, the first time you get an email from Google Checkout that someone has paid you money you will be elated.
Why start here? It’s simple really. If you are focused on getting that one first customer, you will have a different mindset than if you are focused on getting 10,000. You’ll know their names. You’ll call them when they have problems. You’ll get out of bed in the middle of the night if you have to, just to get them to spend $X a month to use your stuff.
You’ll also be less flippant about cost. You’re only trying to get 1 customer, so why get a huge server? You can support one customer with a free (or practically free) account on Heroku. You’ll try hard to make one customer pay as much of the bills as possible.
You’ll also listen to the prospective customers and incorporate their feedback into your application. You’ll learn how much effort it takes to support one customer, and you’ll start to understand how many prospective customers it takes to create one paying customer.
All of this activity will lay the groundwork for your future business. You’ll develop a business model in your head that takes into account the cost of customer acquisition, support, etc. It will show you how to make your business profitable and sustainable.
Note: One of the things you aren’t thinking about when you’re focused on getting your first customer is expensive or broad advertising campaigns. It’s not time for that yet.
Next Goal: 10 Customers
This is the first big test. Can you repeat what you did to get one customer and have it work? Does your conversion rate (prospective customers to paying customers) hold true or spin off wildly in the wrong direction? Can you scale the interaction intensity up without running yourself dry?
Note: the number 10 is arbitrary if you don’t think about context. For a large, expensive SaaS product, that number should probably be 2. If your product is $35/year, then 10 seems about right. And, by the way, you’re still not thinking about advertising.
Can I get 100 people to give me money?
You’re probably starting to sense a pattern here. I’ve got more than ten paying customers, and I’ve learned a lot about my business. My conversion rate is holding steady at about 40%, up from a dismal 2% when I got my first customer. My revenue and my burn rate are holding steady and breaking even, but I don’t have enough profit to build a reserve.
How do I get to 100 customers? It’s finally time to start thinking about advertising. If I need 70 customers to get to 100, and my conversion rate is about 40%, then I need to convince 175 people to try it. How do I do that?
My thoughts turn to places I can advertise for free and target people who might be interested: Facebook and LinkedIn for instance. I can create a “fan” club in Facebook and advertise on groups in LinkedIn.
I also think about how I can add these customers without spending money. I need to preserve some of that revenue so I can have the money I need for my next goal.
And then: 1000 customers open their wallets
Once I’ve scaled my business to support 100 customers, things are a little bit different. I’ll have some decent cash flow, and since my costs shouldn’t really go up I’ll have a small amount of money to spend on advertising.
I don’t have a lot to say about this yet, cuz I’m not working on this goal just yet, at least not in a focused way. But I can see it coming, cuz it’s in my backlog.
Paradise or Purgatory: 10,000 customers
This is as far in the future as I can see. I don’t even know how I would scale up to that. I would need help.
But it doesn’t matter, because this goal is in the icebox and won’t come out until I get the previous goal.
You see, I’m waiting for the last responsible moment, which has yet to come.
For years, this blog has carried the sub-title “Corporate IT Survival Guide”. It was a testament to my efforts to find success and satisfaction in the oh-so-complicated social nightmare that is the corporate IT cost center.
Over the years, satisfaction became more important than success to me. I realized that hating my job was ruining parts of my life. It was hurting my health, my friendships, and my family relationships. It wasn’t hurting my wallet, and right up until the moment I gave up, I was doing reasonably well at the success side.
I don’t work in Corporate IT anymore. I work at a small software company as a developer. I’m responsible for quality assurance, customer support, and some product development. Yeah, I’m like, 2 1/2 IT departments. I think that’s totally awesome.
I always postulated that the reason corporate IT sucks is because nobody sells what IT builds, thus my quest to work at a software company. Now that literally everything I do is sold, I find I really like it. Everything is different. Sure, there are some of the pressures you’d expect from being so close to the company’s revenue, but it doesn’t bother me.
At any rate, I’ve been doing this for a year now and I find I don’t really care about corporate IT anymore. This makes it increasingly difficult to blog about corporate IT. It’s time for a change.
So, as of now, this blog is no longer Tech Dark Side: A Corporate IT Survival Guide. IT is now Tech Dark Side: Struggles of a Self-Taught Coder.
The content is obviously going to change to reflect this as well. Here are some specific changes you are likely to notice:
A lot of talk about ruby and rails
More technical content than I’ve had in the past – it will likely include code samples, tutorials, how-to’s, etc
Less topical focus. This is becoming more of a personal blog. You might notice that I veer into areas I would have stayed away from in the past.
More talk about my side project, TroopTrack.com, and SaaS in general.
I hope this change helps keep my blog relevant to me and doesn’t cause all my readers to jump ship. We’ll see.
Sometimes I struggle, now that I’ve left the dark side (forever), to remember that the old rules don’t apply anymore. When things are going well, it’s easy, but there are occasions when the scars from my decade of toiling away in dysfunctional work environments makes it hard. Times like yesterday and today.
What’s weird about yesterday and today is the context. The thing that triggered my dark-side-reflex was not significant. It was a minor misunderstanding. But, somehow, it conjured up images of a former boss, a person I hated, admired, and often colluded with to get things done as a tool of the evil empire. My ability to do the things that make an organization healthy started to evaporate. Here’s what started to get hard:
Giving others the benefit of the doubt
Admitting culpability in the situation
Appreciating the viewpoint of others
Focusing on the objective of my employment
When we detect ourselves behaving in unhealthy ways emotionally, the secret to getting out of it is simple: Do something healthy about it. So I admitted to those involved (which includes my boss) that I was starting to get cranky about the issue and that, even though it wasn’t exactly right, I might have some difficulty being rational about it.
What would your organization do in this situation? Your boss? Your co-workers?
Mine smiled at me and told me to relax. It was all I needed – a nice reminder that I was free from the Dark Side. The context re-focused, the old boss vibes were gone, and everything became easy again. I could be critical of my own work again, and it felt nice.
It takes extraordinary people to create a healthy work environment. I think I’m the luckiest computer geek alive.
Skills wise, Zend/PHP would be nice, some flavor of agile, plus SQL, Linux, etc. Needs to be someone who’s not afraid of things like Hadoop, graph databases, big-ass search, and the like.
Hobby startups don’t have to be expensive. My startup, TroopTrack.com, has a burn rate of $106 each month. All I have to do is add three paying customers every month and I’ll break even (roughly). Guess what? I’ve been breaking even for almost six months now.
I’ve found that breaking even is very important to Shannon (my wife). She doesn’t mind the time I spend working on TroopTrack most of the time, and she wouldn’t mind investing a little money in a marketing campaign every now and then, but when it comes to every day operating costs, she wants TroopTrack to be self-sufficient, no matter how small it is.
Honestly, I just kind of fell into my financial strategy for TroopTrack (no use pretending it was part of my original grand strategy). But, now that I’ve been in it for over a year I have a real strategy that guides not just how I spend my money, but also how I spend my time. I want TroopTrack to break even there too (figuratively). In other words, I want to spend my time adding stuff the customer can see, not doing things that make no difference as far as they can tell. So, here’s my strategy in a single sentence:
Operationalize TroopTrack in a way that optimizes the amount of time and money I can spend adding new features, supporting existing customers, and adding new customers.
Given that strategy, here are a few of the ways I’ve implemented this.
Investments to Avoid Until You Need Them
Hardware – Don’t buy hardware, just rent or borrow it. Make sure to choose a host that is inexpensive and has a good reputation. Only get one environment – production. If you REALLY need a test environment run it on an old PC – you probably have six in your closet. Start with the smallest environment you can and only upgrade it when customers complain about performance (or you have some other clearly demonstrable problem requiring an upgrade). I recommend Heroku for Rails apps or SliceHost.
Billing Solutions – Keep this as simple as possible and don’t bother automating it until you really need to. TroopTrack billing still isn’t automated – after a customer makes a payment I have to manually mark their account as paid. Trust me, at three transactions a month I can keep up. Frankly, at 100 tx/mo it wouldn’t be a problem – Shannon would be happy to do it at that point. I recommend Google Checkout – it only took me about ten minutes to add payment through Google Checkout to TroopTrack. Avoid any service with a monthly fee. You don’t need those guys until you need them.
Provisioning- Cell phone companies didn’t start out with phones that provisioned themselves when you turned them on. New customers had to walk through manual steps, usually with the aid of an expert, for YEARS and that industry still took off. In the same vein, don’t go to huge lengths to automate everything related to adding new customers, at least not until you need it and you have enough experience to know what it should be like.
Investments You Should Make Early
Help Desk- don’t roll your own. It will suck time away from real development. For less than $10/month, you can get a Help Desk with forums, SLAs, single-sign-on and other great features from ZenDesk. Your customers will love your help desk, and it will save you countless hours and help you avoid costly mistakes with your customers.
Source Control - Sure, you can install git or svn on your own computer and keep your code there, but don’t. It’s just another thing you have to maintain yourself that also limits how you work with others. Just buy that private GitHub account (less than $10/month) and let them handle it.
Backups- Your hosting company probably has a backup option for your server. Get it. You don’t want to lose customer data or have to start over. This is usually pretty inexpensive as well.
Here’s what my monthly burn rate for TroopTrack is:
- Hosting @ SliceHost: $70
- Backups @ SliceHost: $20
- ZenDesk: $9
- GitHub: $7
Grand Total: $106 per month
Many people spend more than that on coffee in a month.
I am going to add another big expense soon – I’m moving all my email over to RackMail. That’s gonna cost me another $3 each month. So put down that Latte – you just paid for next month’s email server!
I started this blog years ago when I first began to suspect that creating software in corporate IT was different from creating software in a software company. I called IT the dark side of technology, based on a belief that the fact that IT products are generally not sold on a free market and therefore is incentivized in completely different ways, generally to the detriment of their work product and the skill and engagement of IT workers themselves.
Well, eventually I found my way out. I work at a real software company, and I have for 13 months now. So, now seems like an appropriate time to answer the question I knew was coming: Is the grass really greener on the other side.
I’ve never felt skilled when it came to crafting the look and feel of an application. There were two components to my feelings of inadequacy: 1) Not understanding CSS and 2) Not being terribly artistic.
The CSS Anthology has really gotten me past #1, and as a result I’m discovering that I am better than I thought at making a web site look good.
Here’s what I like about this book:
It starts with the basics.
I think a lot of my struggles with CSS were the result of never learning the basics. The first chapter of Anthology, “Making a Start with CSS” was really very helpful to me. It filled in the gaps of what I had guessed by hacking at CSS with a much better grasp of what CSS does and how styles get assigned to elements. It was a mini-course in remedial CSS, and I really needed it.
It gets progressively more complex.
I really found the way the recipes got progressively more complex throughout the book helped me to learn effectively. Perhaps this is because I’ve always been such a CSS hack, but the learning increments from chapter to chapter were just the right size. I read the book on an airplane and found I could grok it all the way through.
It’s a cookbook with a strong index.
Want to know how to make a box with round corners? Or remove the default styling from an unordered list? Anthology answers 101 questions like this, and I’ve found the index is very useful for finding solutions for the problems I encountered as I worked on re-designing TroopTrack.com.
If you’re feeling weak with CSS, get this book. It’s really very good.
