David Cummings on Startups

Category: Tech

  • The Massive Differences Between Installed Software and Cloud Startups

    Being in the installed enterprise software world for a decade and the cloud/SaaS world for over five years now, there are massive internal differences between these two types of startups. The business models are inherently different, and should be viewed as such, even though both are full scale software companies.

    Here are some of the massive differences between installed software and cloud/SaaS startups:

    • Installed software companies typically provide releases every 3 – 18 months whereas cloud/SaaS startups push releases multiple times per day creating a different dynamic around time-to-market and scope of functionality
    • 10% – 20% of engineering efforts for installed software companies are for debugging issues that are network or environment specific compared to cloud/SaaS companies that control all aspects of the data center hardware
    • Installed software vendors often have more lock-in and higher switching costs compared to cloud/SaaS vendors  due to the heavy customization and internally managed servers
    • Getting the majority of the lifetime value of the customer up-front with installed software makes it easier to cross the desert to profitability, but creates lumpier quarterly revenue and predictability compared to cloud/SaaS startups with recurring revenue

    Installed software and cloud/SaaS startups have massive differences, and startups should think through the pros and cons of each.

    What else? What are some other differences between installed software and cloud/SaaS startups?

  • Being Too Early with a Startup Idea is a Failure

    Last week I was on a panel at the Digital Summit conference with well over 1,000 attendees. One of the panelists with me was Todd Sawicki, an entrepreneur in a high growth startup that recounted how his previous seven ventures were a failure. One of the comments that he made really stuck with me:

    If you’re too early with a startup idea, that’s a failure just like any other.

    Many entrepreneurs don’t realize that after running out of money, being too early with an idea is one of the most common reasons for failure. Todd told how he worked on a startup that was similar to YouTube, only it was 1997. He also talked about working on a startup that was similar to Dropbox/Carbonite/Mozy, but that it was 1996. Being too early with a startup idea is a failure and happens all the time.

    What else? Do you think being too early with a startup idea is a failure?

  • Physical Technology Upgrades for Startup Offices

    Modern startup offices should be forward looking and take advantage of the latest tools for the job. As an example, large LED TVs are much better to use compared to projectors due to screen resolution, warm up time, sound, and energy consumption. Here are a few physical technology upgrades startups should think about for their office:

    • 65 inch LED TVs with 1080p and VGA/DVI inputs instead of projectors and screens (will be even better with OS X Mountain Lion and AirPlay from a laptop straight to the screen via an AppleTV)
    • Dual 50 inch LED TVs for the scoreboard in the lobby/sales bull pen with one showing real-time data with a number of metrics while the other shows the three most important KPIs highlighted in red, yellow, green, and super green
    • iPads outside each conference room with Google Calendar showing room availability mounted to the wall via a PadTab
    • Entry-door cameras with night vision and a built-in DVR for security and after-hours guest monitoring

    While these technology upgrades aren’t necessarily cheap, they help make for a more efficient and productive working environment.

    What else? What are some other physical technology upgrades startups should think about for their office?

  • Email is Your #1 Security Weakness

    When people think of cyber security and identity theft one’s email account doesn’t come up nearly as often as it should. An email account is the number one security weakness for 99% of the startups out there. Just think about the “Reset Password” option for the sites you use on a regular basis — online banking, QuickBooks Online, Amazon.com, Google AdWords (a savvy bad guy can run up your bill driving traffic to an affiliate program in China), etc.

    Jeff Atwood’s recent post Make Your Email Hacker Proof recommends the same solution I recommend and use personally.

    All startups should use Gmail with two-factor authentication enabled for personal and business email. Yes, it makes it more annoying to sign into Gmail from a random laptop but it’s totally worth it. The idea is that you sign in like you normally would with a standard password and then you use a separate program on your smart phone (or get a number texted to you) that has a random second password. This second password is the key since it is much harder to steal as it changes every 60 seconds and is created on the fly.

    If your email account contains important information or is connected to another account that’s important, and has a “Password Reset” function, Gmail with two-factor authentication is the way to go.

    What else? Do you agree that email is your #1 security weakness?

  • Tungle.me + Email Signature = Self-Service Meeting Signups

    I’m a fan of Tungle.me, the service owned by RIM/Blackberry, that allows for collaboratively scheduling one or more Google Calendars. With Tungle.me you can also make your personal calendar selectively available to anyone that you provide a custom link, while blocking out days / times of day, and making the contents of any already scheduled events say “busy.”

    Sales people have a killer feature on their hands: they can put a personal Tungle.me calendar URL in their email signature and say “Schedule a demo immediately.” The prospect or contact they’re emailing can click that link and schedule a time to talk, which automatically sends an email to the sales rep notifying them of the new event.

    I was skeptical at first if anyone would take the initiative and schedule a demo with a sales rep this way. Now, I’m a big believer as I’ve seen it happen many times. It works great!

    Tungle.me in an email signature results in self-service meeting signups, which is awesome for sales people.

    What else? What are your thoughts on using Tungle.me in email signatures to make it easy for people to schedule meetings?

  • Large Customers as Edge Cases with SaaS Products

    Software-as-a-Service (SaaS) is an extremely efficient model for product development since the delivery components and upgrade cycles are controlled by the vendor (an inordinate amount of time is spent supporting configuration environments with installed applications). There’s one edge case with SaaS product that isn’t talked about much: unusually large customers.

    In the installed software world, unusually large customers typically require more expensive or exotic hardware and the problem is somewhat solved. With SaaS it isn’t as easy because SaaS applications are often sharded whereby clusters of customers are grouped on the same database, but individually delineated. As the customer base of the product grows, the SaaS company adds more and more shards. This breaks down with an unusually large customer when the customer is so large as to not fit in an isolated shard or with the standardized hardware used to power the other shards is not powerful enough.

    Modern technologies like Cassandra and HBase provide amazing scalability across a cluster of machines and solve the scale problem. Unfortunately, the tools to develop against them aren’t as simple and powerful as tools for standard databases like MySQL and PostgreSQL, but they are rapidly improving.

    Some ideas to deal with the unusually large customer edge cases with SaaS products include the following:

    • Data size allotments with fees for additional storage
    • Setting upper-bound limits for certain categories of data and not allowing overages
    • Isolating the account to a dedicated shard

    My recommendation is to think through scalability limits early on and address them in advance of customers reaching them.

    What else? What thoughts do you have on large customers as edge cases with SaaS products?

  • The Scalability of a Programmer’s Effort

    Recently I was talking to a friend of mine who’s an attorney. We were talking about how most law firms operate with an intense focus on the billable hour including a number of tactics around CYA and risk mitigation that result in more dollars billed to clients. As an example, each year we get an external financial audit and as part of it they’re required to ask our law firm if we have any outstanding litigation, and that results in a $500 lawyer bill because each of the corporate-related departments has to chime in and say they don’t know of any thing. That $500 is a waste but I understand why it happens. I was excited to read that in England they passed a law allowing non-lawyers to be equity partners in firms that offer legal services. That’s right, in the United States you can’t own part of a firm that offers legal services unless you’re a lawyer — how crazy is that?

    Law firms live and die by the billable hour due to a number of reasons one of which is the scalability of their efforts. Think about it: for each client they use boiler-plate documents but then spend extensive time customizing them to the situation, and there are always a thousand permutations. There are some economies of scale for senior lawyers with the associate pyramid scheme whereby junior people work hard for several years in hopes of becoming a partner, and the big pay increase that comes with it. Now, contrast that to the scalability of a skilled programmer’s efforts.

    A skilled teenager can write software in his dorm room to help with the dating scene on campus and become a billionaire many times over less than a decade later (Facebook). The power of software is astounding. In fact, software is eating the world according to Marc Andreessen. With the proliferation of open source providing re-usable components at no cost, cloud computing for infinite scalability, and smart phones in millions of pockets the scalability of a programmer’s effort increased by a magnitude, if not more.

    Of course, without users or customers the value of a programmer’s efforts can be minimal but for startups that make it, economies of scale of software engineering is astronomical. Pinterest had over 10 million visitors last month, been in business a couple years, and yet only has 16 employees. The scalability of a talented programmer’s effort is incredible.

    What else? What are some other thoughts on the scalability of a programmer’s effort?

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