David Cummings on Startups

Blog

  • Automated Billing for Startups

    Automated billing is hard — very hard. When starting out the tendency is to try and guess how things might work when it comes to billing and to start building a module for it. Don’t. The best thing to do is to get the product in the hands of customers and then iterate based on their feedback.

    More often than not the product pricing and billing nuances will change several times as you work towards product/market fit. Time spent on a billing module, that needs to be modified with each pricing change, will actually make you more reluctant to change the pricing model because it’ll involve more billing module rework.

    The best thing to do is to bill by hand or use a semi-automated tool like CheddarGetter until you have enough paying customers that you’re confident it’s worth the time to build a billing module or write logic to integrate with a billing system’s API. Avoid the temptation to write a billing module too early.

    What else? What are your thoughts on automated billing for startups?

  • Platform-as-a-Service Options like Heroku for Startups

    Aarjav asked about Platform-as-a-Service (PaaS) options like Heroku in the comments of yesterday’s post Cloud vs Colocation vs Managed Hosting for Startups. PaaS is great in that it offers the benefits of cloud computing with easy scaling up and down while encapsulating many of the more tedious system administration functions present when doing it yourself.

    Heroku, owned by Salesforce.com, is one of the best known PaaS providers, especially in the Ruby community (they support other technologies as well but Ruby is still the most prominent for them). As an example, if you write a new Ruby on Rails application, to run that application you have to set up an environment and maintain it. Manual setup might take an hour if you know what you’re doing or 5 – 10 hours if it’s your first time. With Heroku, you can get things running in 5 minutes in a super simple fashion and as you scale or need more horsepower the process of resizing an instance or adding more instances is much simpler than a traditional cloud or dedicated server model.

    Heroku runs on top of Amazon Web Services (AWS), so it is even more expensive than AWS EC2 instances, which are much more expensive than managed hosting which is more expensive than colocation. Out of the box, Heroku is great and fits in with my recommendation for startups to start with the cloud. Heroku does do things like kill web requests that take longer than 30 seconds, which forces code changes like using more background jobs, which is the right way to go but might cause more code refactoring sooner than desired.

    Startups using a language like Ruby and a framework like Rails are well suited to start with Heroku and graduate from there as their success permits. Startups using a language like PHP have PaaS options like PHPFog to use as well to cut down on administration time and focus on building a business. Long term, PaaS falls under specialized cloud solutions and so the same thoughts around constant availability vs burstable needs, etc still hold true.

    What else? What are some other considerations for Platform-as-a-Service options for startups?

  • 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?