David Cummings on Startups

Blog

  • Cloud vs Colocation vs Managed Hosting for Startups

    With all the talk about cloud computing it’s easy to forget that there are two other common types of hosting for startups: colocation and managed. In a cloud computing environment the servers are virtualized such that a physical machine is often shared by one or more customers and it’s easy to scale up or down as needed (shared hosting and VPS setups fall under cloud computing). Colocation and managed hosting are similar in that the physical machines are dedicated to the customer, but differ in who’s responsible for the actual hardware costs and maintenance, and thus the monthly fee. Colocation is a bring-your-own-hardware approach whereas managed hosting is renting the hardware from the provider.

    Here’s how I think about cloud, colocation, and managed hosting in the context of startups:

    Cloud

    • Good for starting out when server needs are unknown and it’s easy to scale up and down quickly
    • Best for environments that have differing scale needs on a regular basis (e.g. imagine you normally need 20 servers but for a few hours each night you need 100 servers to crunch data)
    • Great for an on-demand infrastructure backup (e.g. replicate the database data but don’t turn on all the other necessary servers unless another facility goes down)
    • Higher latency on average

    Managed

    • Best for the core infrastructure in a 3 – 25 server environment where a relatively constant amount of horsepower is needed (most startups operate this way) and capital is not as plentiful (renting a server is more capital efficient than buying it when getting started)
    • Cheaper than the cloud on a per-server basis but more expensive than colocation assuming a low cost of capital

    Colocation

    • Best for maturing startups that can afford acquiring servers and personnel to manage them
    • Requires more effort and management compared to cloud and managed
    • Maximum flexibility regarding the hardware used (e.g. fancy servers and storage configurations)

    In general, I recommend startups start with the cloud using an environment like Amazon Web Services and then move on to managed hosting followed by colocation as the business progresses.

    What else? What are your thoughts on cloud vs colocation vs managed hosting for startups?

  • Site Speed is a Competitive Differentiator

    Have you ever left a website because it was too slow? Go ahead, raise your hand — I know I have. The speed of a site is analogous to the travelling speed on a road. If you’re driving along on one road and traffic starts to slow down, you’ll take a different route, if possible. Online, the same thing happens all the time.

    37signals has a post up How Basecamp Next got to be so fast without using much client-side UI and the whole post is about making the app fast. Really fast. In fact, after reading the article, it appears one of the main reasons they’re re-building the product from the ground-up is to make it much faster. I’ve used their current product and it feels fine. Making their product 3x faster will make it feel great.

    Rigor (web performance management) has a new tool that will grade the performance of any public website and breakdown all the issues, much like YSlow, but this is generated on the server-side so that it is shareable and doesn’t require a browser plug-in. Take a look at speed.rigor.com and give it a try.

    Site and app speed is a competitive differentiator and should be treated as such from the beginning. It is much easier to start with a fast site and ensure it remains fast than to retrofit a complicated one later.

    What else? Do you agree that site speed is a competitive differentiator?

  • Startup Investment for Short-Term ROI or Long-Term Enterprise Value

    As a startup there are a number of different ways to invest precious capital. Some investments, like building a minimum viable product, are obvious whereas others like buying ads on Google vs LinkedIn aren’t obvious until some modest amount of money is spent. Well, there’s another area that needs more thought from entrepreneurs: investments that don’t have a short-term return but do create significant long-term enterprise value.

    Let’s look at an example to see long-term enterprise value in action:

    • On average it costs $500 to generate a new customer that pays $1,000 per year
    • Revenue is recurring and has 70% gross margins, so $500 in customer acquisition gets $700 of gross margin in year one
    • Customers stay for an average of four years ($4,000 in revenue at 70% gross margin results in $2,800) — customers staying for an average of four years implies a 75% per year renewal rate (1/.25)
    • Enterprise valuation for the company is three times the annual gross margin
    • An opportunity arises to acquire more customers at $1,500/each which results in a year one loss ($1,500 > $700 gross margin) but is profitable over the average lifetime of the customer ($2,800 lifetime gross margin) and increases the value of the business $2,100 (3 x the $700 gross margin)

    In this example, assuming no cost of capital and no discount for future cash flow, spending $1,500 to acquire a customer that pays $1,000 per year, easily pays for itself when looking at the lifetime value of the gross margin of the customer and the long-term enterprise value of the business, assuming OK renewal rates and readily available access to capital. It’s important to get a complete picture of the value of a customer when determining the amount to spend that still generates a positive return on investment.

    What else? What are your thoughts on startup investments for short-term ROI or long-term enterprise value?

  • Blog Post Number 1,000

    A little over five years ago in January of 2007 I set up this blog and published a simple hello world post. My goal originally was to do one post per week but after a few weeks it turned into 1-2 posts per month, if that. Fast forward to August of 2009 and I was inspired by Fred Wilson and him writing a post every single day, 365 days a year on avc.com — I decided to write a post every single day as well. Well, after more than two years of writing a daily post I hit today’s nice little milestone on the journey: blog post number 1,000.

    This blog has improved my life in several ways:

    • Numerous ideas that I’ve encountered over the years are now captured in written form
    • Several employees and partners have come from people reading or referred to me by people reading this blog
    • Many of these posts plus new content were turned into a book called Startup Upstart that is now available on Amazon.com (launching at Startup Riot)
    • Friends and colleagues in the community reference blog posts during conversations, giving me a sense of satisfaction that others are reading it
    • Readers submit comments and feedback, helping document additional insights and improving my understanding

    My favorite post of all time remains one of the most popular as well: 50 Things Every Startup Should Know.

    I’m thankful for the first 1,000 blog posts and I’m looking forward to the next 1,000.

  • Transitioning from Profit-Oriented to Growth-Oriented

    Earlier this month I had lunch with an entrepreneur that described a situation I don’t hear about too often: after several very profitable years they wanted to transition from being profit-oriented to growth-oriented. The business was doing well and the market was continuing to mature around them creating a desire to gain more market share at the expense of near-term profitability. It seems pretty simple, right? Wrong.

    Here are a few reasons why transitioning from profit-oriented to growth-oriented was more difficult than expected:

    • Angel investors in the company had grown used to the nice dividends each year and didn’t want them to stop
    • Internal team members were the operationally-focused type and not growth-focused (good people but not necessarily right for the change)
    • Certain managers that excelled at their current size were viewed as not yet having the skills to take it to the next level, and would have to seriously improve or move on from the business

    It was interesting to hear about these experiences first-hand as well as the challenges that come from making a dramatic strategic change.

    What else? What are some other challenges with transitioning from profit-oriented to growth-oriented for a startup?

  • Product Features that Don’t Fit

    Last week I was working in a web-based product and I came across a feature that didn’t fit. By didn’t fit I mean that it felt out of place and there’s no way it’s potentially usable by 80% of the users. I’d be amazed if more than 1% of the customers have ever used it — it’s that out of place.

    How did the feature get in the product? Here are a few guesses:

    • It was such an easy feature that it got in the product and out the door before it occurred to product management that is wasn’t a good idea
    • A client had a problem and this was support’s idea to help that one client (even though it wasn’t applicable to other clients)
    • Someone with a strong personality (a sales rep?) convinced others that it was a good idea to help close a new customer

    Much like a supertaster who picks up on disproportionate flavors in food, strong product managers quickly reject features that don’t fit. Do you have features in your product that don’t fit?

    What else? What are some other reasons features that don’t fit get into products?

  • Outsourceable Software Development Projects for Startups

    Technology startups should make software development one of their core competencies. All too often when talking to entrepreneurs I ask the “how are you building it” question and they quickly say they’re outsourcing it — I cringe momentarily. Most of the time they say they really like their outsourcing firm but that things are taking longer than expected due to a number of factors. Software engineering still has a fair amount of art to go with the science.

    Projects that are fairly small and extremely definable are outsourceable for startups. These projects are almost always complementary to the main product and interface via APIs or some other mechanism. Here are some example projects that are readily outsourced:

    • WordPress plugins (via a WordPress expert)
    • Browser plugins
    • Microsoft Office/Microsoft Outlook plugins
    • Simple smart phone apps (ones core to the business need to be done in-house)

    Any software development can be outsourced but I recommend technology startups do their engineering in-house and only outsource related projects that plug into their core application.

    What else? What are your thoughts on outsourceable software development projects for startups?

  • The Main Challenge with Rapid Web App Development

    Rapid web application development is amazing. You can go from idea to prototype in a weekend and start testing the concept with real users in no time. The time and energy it takes to launch a web app is 1/50th of what it used to be 10 years ago. There’s one main challenge with rapid web app development:

    Product development can easily outpace the customer feedback.

    Think about it: users need time to experiment with new features and provide feedback. With a clean code base, no code debt, and frameworks like Rails or symfony, application development is blazing fast. In fact, it is too fast if you don’t have an opinionated vision of what will be included, and more importantly, what will be excluded from the product. Yes, having a culture of experimentation is great, but that needs to be measured against features that are truly experiments, and will be removed if they aren’t successful.

    The next time you high-five your co-founder due to the awesome features just implemented, step back and ask if the pace of development is in-line with market feedback and the new features will be used by 80% of your desired customer base.

    What else? What do you think is the main challenge of rapid web app development?

  • Two Schools of Thought on Scaling B2B SaaS App Data

    Scaling the data storage for B2B Software-as-a-Service (SaaS) applications typically falls under two schools of thought: one or more fully-contained accounts per database or specialized multi-tenant sub-systems that handle certain types of data. There are pros and cons to each approach.

    Fully-Contained Accounts

    B2B apps are often simpler than B2C apps when it comes to data storage. In a B2B app, one account/user doesn’t need to know about another, whereas in a B2C app accounts/users have to have a global context for all other accounts/users (think Facebook Friend requests). Fully-contained accounts can be on individual databases or multi-tenant such that one or more accounts are on the same database delineated by an account ID.

    One analogy I like to use is housing for people. A fully-contained account on a private database is a like a single family home. Multiple fully-contained accounts on one database is like one building in an apartment complex where everyone gets their own space but there are greater economies of scale having everyone together.

    Challenges for fully-contained accounts in a multi-tenant environment arise when the size of the accounts start changing and growing at different rates. Back to the apartment complex example, one family wants a home gym and decides they want a new bedroom for it, only all the other three bedroom apartments in the complex are full. What does the family do? Well if the family can afford it the tendency is to go to a single family home that is suited uniquely to them.

    A single family home is much more expensive to maintain, on a per family basis, compared to a building in an apartment complex. Services like landscaping, security, and amenities like a gym or pool are much more affordable when spread out over dozens or hundreds of people. A single family home can have all those accoutrements but the cost structure is no where near the same.

    Specialized Sub-Systems

    Now, assume some accounts in the multi-tenant fully-contained database approach grow so large that they need their own dedicated database. With the housing analogy, larger families start moving to single family homes from the building in an apartment complex. Assume the apartment complex didn’t have a pool — the app didn’t have that feature yet. Now, the startup decides a new feature is needed — the equivalent of a pool — and adds it to the application. The pool is manageable in the apartment complex that houses 100 families with the cost of chemical treatments, cleaning, etc spread out over a large number of users. For the single family homes that were created by the accounts that got too large, each now has a pool by the nature of SaaS applications having a single code base for all customers, and those pools all need to be managed. Going from pool to pool, even with automated tools and help, becomes less efficient and more costly to do chemical treatments, cleaning, etc.

    Specialized storage and application sub-systems are designed to solve this problem. Think of a simple survey application. The info for the accounts, users, billing, survey questions, and more are pretty simple and not storage intensive. What is storage intensive is keeping track of all the survey responses and survey respondents. That information is going to grow exponentially compared to the core account data. It deserves a dedicated sub-system.

    Now, back to the housing analogy. Instead of families desiring a home gym moving to single family homes, the apartment complex introduces new buildings in the same complex, only the different buildings serve specific functions like a gym with an indoor pool, parking deck, and storage units for for each family. The individual features and storage needs get dedicated attention such that the regular gym with pool can grow into a 100,000 square foot facility with Olympic-size pool, and all the families can stay put in the apartment building that’s part of the same complex. Areas that change disproportionately can get the necessary attention without affecting other aspects of the application.

    Conclusion

    When starting out, fully-contained accounts is easier to implement and doesn’t require much overhead, making it the right choice for young B2B SaaS apps. If data grows linearly and everything is tightly related, keep it simple with fully-contained accounts. As the application grows, and certain types of data grow disproportionately faster than others, specialized sub-systems scale better and in a more cost-effective manner, making them the right choice for mature, data-intensive B2B SaaS apps.

    What else? What are your thoughts on these two schools of thought for scaling B2B SaaS app data?

  • Founder Math for VC Money to Make Sense

    Today I was talking to a journalist who asked a variety of questions about my startup. One of the things he was surprised by was that we’d gotten to our decent size without raising money from VCs. Normally, people mention that it’s unusual and then move on to the next question. Well, he legitimately wanted to know why we didn’t raise money. I quickly explained that it didn’t make sense for 99.9% of startups to raise institutional money for a variety of reasons.

    When entrepreneurs ask me about raising money I like to ask them: what’s your founder math for VC money to make sense? I believe entrepreneurs should build their business to last with no exit strategy, but if you do have a goal of selling it in 5-10 years some founder math related to equity is in order. If you take a look at founder equity at time of IPO you’ll see it’s in the 4-15% range and only 5-10% of companies that raise VC money exit for more than $100 million.

    So, owning 10% of something worth $100M, which would be a phenomenal outcome, and happens a tiny fraction of the time for VC-backed companies (a very high bar), nets you $10M. $10M is a huge amount of money, but what amount of effort and luck is required to make $10M without VC money. To make $10M you could build a business with $6M in revenue, $2M in profit, and sell it for 5x profit for a total of $10M. The “small” exit is 100x more likely of a scenario than the big exit.

    It takes a special situation for the founder math to make sense to raise VC money. It exists, but is rare.

    What else? What do you think of the founder math for VC money to make sense?