David Cummings on Startups

Category: Entrepreneurship

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

  • B2C Startups in the Southeast

    Today I had the opportunity to independently talk with two different entrepreneurs at my office. Coincidentally, both are working on B2C web app startups, whereas most I talk to are working on B2B startups. Each entrepreneur, late in the conversation, volunteered that they’ve found B2C startups in the Southeast few and far between. When it comes to angel investors, they’ve had even more difficulties as investors in the region prefer to see a clear revenue model.

    I believe there are a number of B2C startups in the area, but since it is the minority compared to B2B startups, the sense of community has been more difficult to foster. In addition, B2C startups, all things being equal, have a more difficult time achieving success compared to B2B startups. Here are a few reasons why B2C can be more difficult than B2B in the Southeast:

    • B2C startups often require an even slicker, more polished interface than business apps and good designers are hard to come by (outsourcing opportunity?)
    • B2C startups often need to achieve a significantly greater number of users since the revenue per user is often very low (e.g. $.50 CPMs on advertisements requires a huge amount of traffic to generate a million in revenue)
    • B2C startups, when raising money, have fewer local success stories and exits, to draw from
    • B2C startups need a way to acquire customers in a low-cost manner through viral mechanisms, SEO, and more to achieve economies of scale, and it’s difficult to make that work

    I hope to see a robust B2C startup community develop as there are a number of talented people working on those types of startups.

    What else? What are your thoughts on B2C startups in the Southeast?

  • My New Book: Startup Upstart

    After 18 months of work I’m happy to say that my new book, Startup Upstart, is done. Startup Upstart is the culmination of the best of nearly 1,000 blog posts from this blog. I selected some of the most popular posts, fleshed them out, and wove them together with the help of a great editor.  It’s been submitted to the printers and will be ready on February 22nd.

    We’ll be launching the book at Startup Riot in Atlanta on February 22, 2012 and all attendees will receive a free copy.

    Startup Upstart, much like this blog, is an attempt to document some of my observations and musings on entrepreneurship. Entrepreneurship, as many already know, has been my passion and creative outlet for over 15 years. My goal is to help others not make the same mistakes I’ve made as well as accelerate their time to success.

    I hope you enjoy the book as much I do and I look forward to your feedback and insight.

    Update: The book is launched and available on Amazon.com!

  • Application Performance Over Time for Startups

    Application performance/speed is a feature that’s incredibly valuable. Think about it: if a website or SaaS application performs slowly on a regular basis you’re much more likely to start evaluating other options. For a complex, multi-tenant web app the number of moving parts grows over time making consistent, fast performance more and more challenging.

    Here are some items to consider doing on a regular basis:

    • Evaluate raw database size on the filesystem as well as number of rows in the 10 largest tables (e.g. take a snapshot of this in a table or manually put the values in a Google Spreadsheet once per month)
    • Track the amount of time it takes to complete nightly background jobs and record it on a regular basis for time series analytics
    • Incorporate in-app tools to measure database query execution time as well as log slow queries
    • Measure the page load time of the 25 most important user functions with real browser checks using Rigor.com, or a similar tool, on a daily basis

    One of the key factors is measuring the rate of change and growth over time — it’s best to get out of front of potential speed issues rather than deal with them when they arrive. Application performance is a feature and needs to treated as such.

    What else? What are some other items to consider for application performance over time for startups?