5 Things You Need to Know Before Worrying About Scaling

Scaling sounds very sexy. It’s a problem that every technical entrepreneur wants to tackle. Largely because of the TechCrunch headlines and the sayings that ‘growth cures all’.

Technically that’s not true. If you don’t have the fundamentals right, massive growth can kill you quicker than you can course correct.

There are at least 5 things you want to be able to have right (and know cold) before you start thinking of scaling – or rather, before you raise money to scale.

Disclaimer: All of these don’t apply to every web service – e.g. Twitter, Pinterest, and other ‘land grab’ type services that are a new form that hasn’t been successfully monetized in the past, it may be better to just focus on a few and worry about the rest later. But without further ado…

1. Have you validated your product/service for a market that makes sense to pursue?

Have you found some subset of users that absolutely can’t live without your product/service? Is your product generic enough – that other users can find the same value as those that love you – so they can use it without much customization on your end? Are there more of the user-type that absolutely loves you? 10 60-year old women may love your service, but are you sure it isn’t because your service fixes a problem that only occurs in their neighrborhood? In other words, can you find other 60-year old women that love your service in other neighborhoods throughout the state/country/world?

If you can’t answer affirmatively to the questions above, you have not validated your product for a market that makes sense to pursue.

2. Know your margins cold.

What are your gross margins? What are your net?

You need to understand the difference between the cost of your inputs (Cost of Goods Sold) – which impact your gross margins (i.e. for every dollar of revenue you earn, you HAVE to incur these costs because they make up the product – unless you change ingredients, etc.) and the cost of your overhead (what are the costs that you incur as a result of selling and doing administration).

This is very important, not only because any investor worth his salt will be thinking about these things, because your margins determine your business strategy. If your net margins are high, then your risk tolerance is high…if your net margins are low (and your cash cushion is low), then your risk tolerance is lower.

Groupon is a wonderful example of why understanding these concepts are so important.

Their Gross Margins, for their last fiscal year, were a whopping 69%. Meaning, 69 cents of every dollar that comes in is Gross Profit.

The problem is their SG&A (Selling, General & Administration Expenses). Last reported year, their Gross Profit was: $1.615B. Their SG&A was $1.515B. So literally 93.8% of their gross profits go directly into supporting their sales. This figure has actually improved! Just 4 years ago, their SG&A was 110% of their Gross Profits.

Let us contrast that with say Google – which is similar to Groupon, in that they both have to support people that sell on their platform. Groupon is a bit different because they support both sides of the transaction (vendors & buyers) – but to a large extent, so does AdSense.

Last year, Google’s Gross Margin was 59.13%. Their SG&A was 32.8% of their Gross Profit.

Now I am not saying that you should run away from a business that has low margins (or none in the case of GroupOn), but you should at least understand the numbers so you can know what challenges will come. In a low-margin business, you have a very slim margin of error (pun intended). If your sales dip 1 month, you could be out of business depending on how big the dip and how much cash you have in the bank. Whereas a large margin business has the ability to more easily accumulate cash to deal with those down months.

3. What is the best way to reach your customers?

Going back to those customers that love you from the first point, what is the best way to reach them? An organic SEO strategy, targeted at mom’s that garden? A major billboard on Highway 90 for 6 months of the year? A monthly full page ad in a furniture & wood monthly magazine, starting in Oregon? Guest blog writing for high-profile tech blogs? AdSense? Link Exchange? Banner ads on a premium design-only ad-network?

Of all the ways you have experimented with, which has the best conversion rates and best bang for your buck?

The reason you want to know this before you try to scale, is because it will increase the efficiency of how you deploy the capital you raise. Even if you don’t raise, it will help keep you focused on just the channels that have shown to specifically work for you. Time & attention are money.

4. What will it cost to acquire customers?

Once you figure out how to reach your customers, then you have to figure out how much it will cost you to get them and convert them. Can you just send them into a funnel, or will they require handholding by a physical person (see GroupOn above).

If the Lifetime Value of your customer is lower than what it costed you to acquire them….that’s a losing proposition. You need to either figure out a way to improve their Lifetime Value or reduce the cost to acquire them.

If you can’t do either, then that customer is not worth it – because you can’t build a sustainable business on that customer-type.

5. What is the lifetime value of each customer?

How much money will you make from each customer over the life of their account with you. The larger the difference between this value and CAC (Customer Acquisition Cost – point #4 above), the better.

Evernote & Dropbox are perfect examples of businesses that know the lifetime value of their customer – and they lifetime value is likely to be large. That’s why Dropbox can give away so much storage, because they know that the more you depend on Dropbox it is the less likely that you will leave.

Evernote is even more interesting, because it has a micro-mental-network effect, because the more stuff you store on Evernote, is the less likely you are to leave because the greater the hassle to take everything away and move to another service (especially when Evernote works so well). So they can more or less predict, based on how long you use the free product, when you will convert to paid and how long you will stay a paid customer.

This presentation by Phil Libin (CEO of Evernote) is the perfect example of these metrics in use.

So I hope that I have helped you to think through your approach to your product. You have a lot of work to do before you are ready to scale in a significant way. If you nail down these things, and all of your numbers look right (growth rates are up and to the left, margins are fat, etc.) you have a much higher probability of success while you scale.

Redefining MVP to Minimum Valuable Product

Given our experience working with many clients building MVPs, I have made a few observations about using the term – that lead me to think that a re-definition may be in order.

1st Observation: The term is too geeky

Due to the name of my business, I can’t run away from explaining what an MVP is. Anyone that I have to explain this to, I have to usually explain how a web product is different than a web site. Then I have to explain what a ‘viable product’ is. Then I add the minimum portion of it – to emphasize the ability to get to market quickly to test the hypothesis re: the viability of the product. Viability sounds overly complicated and takes ‘non-tech-startup’ people a significant amount of time to conceptually wrap their brains around determining whether a product is ‘viable’.

I think that is largely because the ‘viability’ in the MVP sense captures 2 concepts in 1. In order for a product to be viable, it must be valuable to someone first. Then some reasonable portion of the market must be willing to pay for it. If a product is valuable to literally 1 person, then for all intents and purposes it doesn’t matter how much they are willing to pay for it – even $1B – it almost makes no rational sense to pursue it. A market size of 1 is basically no market – even if that 1 is the US Gov’t (from my perspective anyway). So you have to grok the valuable part and the market size part – in 1 word.

2nd Observation: Seeking value is under emphasised

Due to the fact that ‘Value’ is not in the name Minimum Viable Product, it is quite often overlooked by entrepreneurs. They know that to validate a hypothesis, they have to find some potential clients willing to pay for it. However, because they focus on just the exchange of money or even the ‘minimum’ allure of creating a handful of features, they don’t quite understand/hone-in on the ‘value concept’ of what they are building. In other words, when you ask them…how does what you are creating add value for your potential customers – they can’t say explicitly articulate what their value is.

The average web developer doesn’t fully understand (and can’t quantify/articulate) their value.

For us, the value we provide is peace-of-mind by reducing your risk. We guarantee you a working MVP for a flat fee of $5K.

Determining true value is a particularly tricky exercise, because it is hard to articulate. Someone doesn’t buy a fan because it has 3, 4, or 5 blades….they buy a fan because it can keep them cool, at a significantly lower cost than an A/C and with much less stress/work than fanning themselves. If a fan has 1 million blades, but doesn’t keep the subject cool…it won’t last in the marketplace – unless there is some other magic that provides some imputed value that the creator didn’t anticipate (e.g. perhaps the cost of the fan is less than the value of some of the components – hey…it has happened).

3rd Observation: Without capturing value, the product will never be viable

If a product doesn’t provide some value, then people will not use it over the long-term. People, especially early adopters, will try your product when they just hear about it…but if it doesn’t provide some value to them…they will not use it consistently over time.

The most important thing about surviving is not just providing value, but capturing some amount of the value you create. That’s the only way to be viable over the long-term. Once you know how much value you create, then you can figure out a way to capture that value.

4th Observation: You need to figure out your ‘Value Delta’

Value Delta = The Amount of Value You Create – The Amount of Value You Charge

Value Surplus = A positive Value Delta

Value Deficit = A negative Value Delta

If you create a product that on average makes your best customer segment $1M+/year each, you are doing them a MAJOR disservice by charging just $120/year. The reason is that your incentives are misaligned. In order for you to be sustainable you have to focus on getting many customers and building an organization around trying to optimize for acquiring multiple customers – whereas those customers that receive $1M+/year of value will likely want you to focus more on improving the product and providing support. If they are just paying you $120/year, you can’t do that right off the bat – therefore you begin to erode your Value Delta.

In this case, you and they, would be much better off if you charged them $120K/year. That would allow you to focus on improving the product and adding more value to your existing customers than chasing down every new customer.

In a theoretical world, a rational customer should want to pay up to $999K/year for your product, because they would still be net-ahead. Now…I wouldn’t advise that, obviously, because it gets harder to justify a small value-delta. The larger the value-delta, the more compelling your product offering…up to a point. So the trick is to balance that value-delta such that the value-surplus is compelling enough for the customer to want to use your product – and that you can build a sustainable business supporting that value-surplus around.

You want to stay away from Value Deficit territory – assuming you want to build something for the long-run.

So, I think the industry needs to re-focus on the value creation portion of an MVP – because that is the only thing that will get the product to product-market-fit. Re-defining the default term is just the first step. You would be surprised how difficult it is to get at the value being created by a product. It’s not as straight forward as it sounds.

I will be writing a few more posts on Value over the next few days, so stay tuned.

Analysis of Market Demand for Web Programming Languages

A few months ago, I got the idea that one way to get leads for remote freelance gigs was to scour Craigslist. So, after doing the manual work of ‘crawling’ through at least 100 job postings by hand, I wrote a Ruby script to do the heavy lifting and filtering for me.

Once I started looking through the data, some interesting things started jumping out at me. Even though I don’t actually live in the Valley (I live in Jamaica), I consume a lot of the news, blog posts and articles that come from the Valley. Suffice it to say, I am affected by the ‘Valley echo-chamber’. One side effect of that is an obsession with Ruby and Rails as my development stack…and a general expectation that the rest of the world has woken up to the beauty and elegance that is Ruby & Rails.

Alas, much to my surprise, that is not the case.

Before diving into the data, let me explain exactly what this script does. Throughout Craigslist, there are two URL subpaths that tend to have the majority of the web development freelance gigs – /cpg/ and /web/.

So the script creates a list of all the cities on Craigslist (because CL doesn’t provide a clean, RESTful API that allows you to get this info easily) and then simply adds /cpg/ and /web/ to the end of that URL.

Then, on each link it checks to see if the current link actually has gigs posted in that city. The reason for this is that whenever there is no gig posted in the current city, what CL does is shows gigs from ‘Nearby cities’. To prevent duplication, the script automagically checks for that and eliminates those cities that don’t have ‘uniquely posted’ gigs. However, it does not eliminate a gig that has the exact text and posted in two different cities – because, well…I hadn’t gotten there yet.

Once the script has a list of ‘valid’ cities with gigs posted, then it starts to parse each of the links on the first page of those cities (i.e. up to 100 links in each city – CL does pagination by the 100 links) for keywords that I specified. The upside to only using the last 100 links in each city is that those are most recent. The downside is that in active cities, the last 100 isn’t always a good sample from the entire population.

For the Rails results, I have the following keywords: “rails, (ruby on rails), (ruby on rails 3), (rails 3), (rails 2)”.

For the Ruby results, I have the following keywords: “ruby, (ruby 1.8.7), (ruby 1.9.2), (ruby 1.9.3), ruby187, ruby192, ruby193”.

The searches are case-insensitive – so any link containing Ruby, rUbY or RUBY will be found and included.

I am trying to capture every permutation that someone would use ‘Rails’ in a web dev sense.

The downside to this ‘basic’ approach is that for technologies that share similar keywords – e.g. ‘Ruby on Rails’ (the framework) and Ruby (the language) – there will be overlap. So in this case, the Ruby results contain a ton of Rails links. i.e. Rails is basically a subset of Ruby.

I have done my best to fine-tune as many obviously spam-like CL posts out of the results, to really get at the legitimate posts.

So it is fair to say, I think, that these results give us a relative proxy for what the marketplace for freelance programming gigs are actually looking for.

Without further ado, here is the data and analysis.

General Stats

  • Cities Parsed: 720
  • Total Gigs Found: 11,992 – 12,076 (footnote: scripts were run multiple times – for accuracy purposes – and the results returned were within this range)
  • Time Script Takes to Run: 16 mins – 1.25 hrs

Languages Searched For

Server-Side Languages & Frameworks
  • C# (C-Sharp)
  • CodeIgniter (PHP Framework)
  • Django (Python Framework)
  • Dot-Net
  • Java
  • Lisp
  • Perl
  • PHP
  • Python
  • Rails (Ruby Framework)
  • Ruby
Client-Side Languages & MVC Frameworks

Batch 1 – Languages

  • HTML
  • CSS
  • Javascript
  • Flash

Batch 2 – Javascript MVC Frameworks

  • Backbone.js
  • Closure
  • Ember.js
  • Knockout.js
  • Node.js

On the server side, you can see that PHP wins by a long shot – with an almost Bolt-like performance, blowing everybody else out of the water. In fact, Ruby comes in at a paltry 5th place, Java coming in at 2nd and Dot-Net and C# coming in 3rd and 4th respectively.

The most surprising result from the above is that Flash is still in demand – with all the “Flash is dead” rhetoric flying around the tech presses and blogs. Almost as much in demand as Javascript! Who woulda thunk?!?

As for the Javascript frameworks, there is a silent battle going on with the multitudes of Javascript frameworks in existence and being released regularly. Here is where the unscientific-ness and impreciseness of this little exercise rears it’s head again. Upon first glance of the results, the script says that Ember had an output of 14 gigs. However, because the keyword being searched for is ‘ember’, what happens is that Ruby finds any string with a substring of ‘ember’. So it had 14 links with ‘Member’ and ‘Membership’ in the link title. Not one with Ember.js or the Ember we were looking for. So after I manually reviewed the links, 0 results were returned. So the only two client-side MVC frameworks that the script found that is in-demand is Backbone and Node. Both, just barely.

That being said, please take that with a grain of salt. Here is an alternative data point for you.

I was told by one of the founders of GroupTalent a few months ago, that the largest demand from clients they are seeing is in-fact for client-side JS frameworks. Even more so than server-side frameworks.

Here is all the data altogether.


This post is not meant to start a flamewar between the various camps. It is just an unscientific analysis of what the general marketplace (using Craigslist as a proxy for that marketplace) is looking for in web development talent.

If you are considering learning one of these languages or frameworks, using what the marketplace requests is one factor to weigh in your decision making process. I wouldn’t necessarily encourage that though, I certainly didn’t.

I chose Ruby & Rails and love every minute of it. I would encourage you to try out various languages and see which you feel most comfortable with – because the vast majority of the time you spend in the language (assuming you really want to get better) will be non-billable stuff.

In the web applications I build for clients at 5KMVP, I use Ruby & Rails because that’s what I love. Clients have been satisfied and seem to love it too.

If you want me to do an analysis of anything else – say Mobile vs Server languages or anything else, let me know in the comments or drop me a line on Twitter.

If you found this interesting, you may find a piece I wrote about Dropbox, or a guide to understanding cashflow vs profit, similarly interesting.

You can find the Ruby script I created on Github, along with some sample output files that have a list of all the gigs generated for this article.

Do look around and if you submit any pull requests for any improvements you may have, the Karma Fairy shall multiply your lineage ten-fold and your seed shall outnumber the celestial bodies.

Why Developing With Rails Is Fun and Pleasant

Disclaimer: This post is NOT for experienced Rails developers. It is for designers and non-developers thinking about diving into code and trying to decide which language/framework they should use.

Why did I learn Ruby & Rails?

I am fairly new to Rails & Ruby. I just started learning about 8 months ago when I started developing CompVersions.

CompVersions is a web application that allows designers to upload multiple versions of their designs – so that their clients can easily give them a thumbs up/down and add comments as necessary.

The idea for CompVersions comes from my previous experiences working with multiple designers. I have, at various points in the past, worked on projects where I was either project lead or project manager and had to coordinate designs and feedback from multiple designers and multiple stakeholders.

Getting & forwarding emails with PDF files as attachments and notes specifying the line and page number in the PDF was not cutting it anymore. I tried Basecamp, and it wasn’t designed for this problem, so it didn’t work the way I needed it. So I decided to build my own solution.

Why write this post ?

A friend of mine (wassup Hector) is doing a similar journey (i.e. building a web app/site while learning), but he is in Microsoft land (Dot Net, IIS, MSDN, the whole nine yards).

I was explaining to him why I love Rails & Ruby, and how it completely abstracts the pain of doing things like SQL queries (although, if you want to work with SQL you surely can).

I was trying to find a real-world example of what I meant, but all I found were the regular ‘build a blog in 15 minutes’ and tutorials and articles that take you through the entire app process. I didn’t want that, so I started looking through my code. I realized that I have the perfect use case to highlight how wonderful it is to use Rails. He appreciated it, and understood what I meant, so I figured I would write it up and release for everybody else.

What is my example?

Rails is known for allowing the developer to focus more on the business logic of the application, rather than the technical behind the scenes stuff.

What does that even mean? Here is an example:

I was hooking up the email functionality where once a designer registers they get an email from the app. I use a rails gem (the equivalent of a plugin) called devise that makes it relatively easy to get up and running with an authentication solution. It handles users logging in and out. Registering, forgotten and resetting passwords. Locking and Unlocking an account (say if your application requires high security where you only allow X login attempts, then the account is locked). Plus a few other features. All in one plugin. All done to industry standard best practices – e.g. when a user forgets their password a unique link is sent where they can reset their password (i.e. a password is not sent via plaintext in email, that’s very insecure). I get all of this functionality with very little effort (relatively speaking given the amount of functionality I get).

So the first question I was faced with is, how do I address the designer? Do I say “Hi John!” ? But what if there is no first name, how do I fallback to their username (sexyjohn79) and then subsequently their email (sexyjohn79@email.hotmail.com). That’s ‘business logic’.

How do you implement this business logic?

The registration form for CompVersions has First & Last Names, Usernames & Email addresses. A user can login with both their username and email address. But I haven’t decided whether or not I am going to let first & last names be mandatory. Most likely will, but I wanted to implement it to gracefully handle the situations when it doesn’t have one or the others.

Rails uses what is called an MVC structure. Model, View, Controller. Rails encourages you to put all of your business logic in the ‘Model’ portion of your app.

Show me some code, damnit!

In my User model (which is where Rails handles all the business logic related to the ‘Users’ of the app), I have a method called pretty_name that handles this option. This is how my pretty_name method looks:

def pretty_name
    f_name || username || email

Please explain that code to me

To break it down for my non-developer friends out there:

Line 1 is the definition of the method. The method is what I will call to ‘execute/invoke’ this block of code. This will become clearer shortly.

Line 2 basically says “If the value f_name exists, return that value” – i.e. if there is a first name (or if the first name is NOT null) return the first name. Then it moves on to say “…OR ( || = OR ), if that doesn’t exist check to see if a username exists. If it does, return that value…” and continues to “…OR if no f_name and username exist, return the email_address”. The assumption here is that a username MUST exist because the user will be getting this message in their email. Ruby executes left-to-right.

Line 3 ends this method

That’s it. That’s the business logic.

Then, in my template for the actual email (i.e. the ‘View’ from the MVC), this is what the first few lines look like:

<p>Hi <%= @resource.pretty_name %></p>

<p> Thank you for registering with CompVersions.</p>

The system says Hi and it executes the method pretty_name on the object @resource (@resource is an object that devise – from earlier – uses to refer to the current user account) and then returns the best value. So if the person’s first name is John and it is there (i.e. the value is not NULL), the email will say Hi John. If there is no first name, it will say Hi sexyjohn79, where sexyjohn79 is the username. If there is no username it will say Hi sexyjohn79@email.hotmail.com.

Here is an example of how the end product looks. All for the simple Hi Marc!

So is Rails really a walk in the park, for non-developers?

I don’t want you to misunderstand what I am saying. I am not implying that in order to get from nothing to a full app with login, for a non-Rails developer it is easy and quick. It’s not that easy. But as a general rule, the things you will be struggling with (once you get the basics down) are how the app will function – the business logic – rather than missing semi-colons and errant SQL queries.

Like all languages and frameworks, it has its quirks. Rails has a set of conventions that make sense and force you to develop one way (many consider it ‘the right way’). There are some that it doesn’t work for. It has worked for me, and makes total sense – based on what I have seen so far.

I hope that helps encourage you to try Rails, or even consider it for your next project.

There are many awesome tutorials out there, for starters I would use Rails for Zombies. I am in no way affiliated with them, I just love their product.

If you liked this, you should follow me on Twitter here.

Here are some more screenshots of CompVersions:

Learning Ruby on Rails, CSS & jQuery

This is what my development environment is:

For learning Rails I tried MANY things:

  • Rails Tutorial (this was a nice first primer, but given that I was learning Rails from scratch the issue I had with this tutorial is that it forces you to learn Test Driven Development – which for me was too much to learn everything at once. So I skipped over all the Test related stuff, and picked up what I could from everything else).
  • Rails for Zombies – this is pretty awesome, because it doesn’t involve Tests and takes you into the core of Rails 3 from day 1. I highly recommend this for anyone just starting Rails development.
  • I tried a few ebooks – and they are nice for rounding out your knowledge (once you have a solid understanding of the Rails way) and giving you an alternative perspective, but they never quite got me to fully understanding the way things worked.
  • Asking Questions – mainly on Stack Overflow and #RubyOnRails on IRC.Freenode.net, port 6667. Every now and then, I will ask a question and get a WONDERFUL answer. Not only did his response clear up some stuff in my mind, but I have since used his advice about looking at other live examples.
  • Bookmark and constantly refer to multiple git repositories. Specifically the Facebook competitor Diaspora, Sassy, and Shapado.
  • Railscasts are awesome, once you have the basics under your belt. They really help you do specific stuff in Rails.
  • Just diving in. CompVersions was my first Rails app, and it has been a steep learning curve. Very steep. But I feel MUCH more fulfilled having done everything the hard way. That approach might not work for everyone else, but that’s what has worked for me.
  • I must confess that I never focused on learning Ruby, but now that I have a certain foundation in Rails and a bit of Ruby under my belt, I do plan on learning more Ruby.
  • Ironically, writing about my learnings also helps. There is something about explaining that forces you to understand what you are talking about.

I also had to learn (and am still learning) jQuery which I pretty much took the same approach.

Here are some additional CSS resources I used in my journey: + HTML5 & CSS3 lecture by Paul Irish (member of the jQuery core team) + A WONDERFUL CSS3 Practical Introduction. It really is difficult to speak too highly of this presentation, except to say that you have to see it for yourself. + A very straight forward tutorial on CSS selectors and the way it works. + It’s also very important for you to understand the Document Object Model (DOM) tree + Here is a nice collection of CSS3 buttons, made in the likeness of Github buttons. + Net Tuts has a nice rundown of 30 CSS selectors that are useful.

I apologize if this is too much of a link dump, but people constantly ask me what resources I used to learn everything and I have not been able to point them to one comprehensive place for me. But now I can :)