Hacker News Reader

On your point #3. Actually, you are incorrect. Profit is revenue - all costs. Whether or not it counts as COGS is only relevant for gross margin, a metric which isn't the best to judge software companies. R&D is an expense, so it affects your profitability and your net margin. If your company spends $100 less, that's $100 more you have in the bank, $100 less that you need to sell people on.

http://www.investopedia.com/terms/g/grossmargin.asp http://www.investopedia.com/terms/n/net_margin.asp

gross margin is unquestionably the metric used to gauge software companies. That's why we are so scalable. Especially SaaS. It's because our COGS are typically so low that we can afford relatively large R&D budgets (compared to other industries).

Lots of software companies have gross margin's north of 60% or even 80% (GOOG, afaik) which is unheard of in other industries.

If you focus your business on growing revenue and having a reasonable gross profit margin, you are focusing on the right knobs. If you are focusing on decreasing R&D as a means of maximizing net profit, you are focused on the wrong things.

> PHP sucks, but there are a ton of profitable companies that use it because it is wicked wicked fast. In my mind, that makes it suck less. :-)

I think in this mini benchmark, it's not so much that "PHP" is fast (as a language, it isn't, really), rather that Ruby + its various frameworks are pretty pokey.

In any case though, while I remain a Ruby fan, the grandparent sort of misses the point: by being more efficient, you have a wider range of things that can make you money. If you have to have a huge amount of resources to get some pages up, doing ads or some other low-margin activity might not even be feasible like it would with a faster solution.

You're actually on to my point which is to stop doing low margin activities and focus on high margin activities. Low margin activities are where writing a page in C / C++ might be a really good idea. The performance critical parts of your site can always be rewritten in assembler if need be.

If your margin on a page request is 5% your business is probably fucked anyway (unless your serving billions of pageviews per month, there are only a few sites that work on this business model). I'd much rather have a business with orders of magnitude fewer requests and a profit margin on the order of 10s of thousands per page request.

What do you think 37Signals margin on a page request for basecamp is? My guess is at least 10,000%.

"You're actually on to my point which is to stop doing low margin activities and focus on high margin activities."

That's something I would certainly endorse. I didn't get that out of your post, I completely agree. Engineers who start companies often overlook this fact and focus on the entirely wrong set of problems when building their business.

I shouldn't have thrown in that line about PHP, that was a total tangent. And in any event, I agree with your response. :-)

My point is that out of the gate I'd rather have 2011 tools running on 1999 hardware than 1999 software running on 2011 hardware. A 2011 dev team will run circles around a 1999 dev team because their tools are better and allow them to iterate much more quickly. By the time your startup overwhelms a Pentium 3 server you should have enough profit to by new stuff.

Good luck getting a PIII to serve Ruby on Rails content fast enough to keep people interested and cheap enough to still make a profit from advertising.

I actually tried this recently. Page load speed isn't too bad at all, but the time it takes to start up the rails stack is awful. It's unusable for dev work.

OTOH, his shorter time to market also imply smaller product cost. With that difference, it could make sense to invest in beefier servers.

You could end up having 2011 technology on 2014 servers competing with 1999 tech on 2011 servers.

  AMZN and GOOG have proven that pageload speed does in fact
  directly relate to profitability.

Let's not forget that's the client side speed not a server side. The difference is important: the time to generate html on the server may be just 10-20 percents of total load time.

On the other side, client-side optimization does help your servers: imagine if you cut from 60HTTP requests to just 6—and did that with proper caching policy, so your servers won't be hammered on subsequent page loads just to answer "304 Not Modified".

Ever since I got interested in client-side optimization (a bit over two years now) I am amazed how neglected this aspect is. I may be biased, of course.

What's stopping you from profiling your rails app after you finished it before the home built php solution? You always want to decrease development time, product out the door is what matters as Windows and Linux/Unix prove that even with superior alternatives (plan9, inferno) being first and with momentum is infinitely more valuable.

As per point #3, remember that you amortize the cost of r&d along some payback period. As such it does effect your margins.

I do agree with your point though. Decreasing development time is the means to the end of making more money out of the product and making a greater return for your (money/time) investment.

Page load speed does relate to profitability, but your language choice most likely won't move the needle so far that you notice a difference. My startup's Rails-based homepage averages ~11ms render time.