How Startups Become 10x Less Efficient at Releasing New Features (or, nSpeed)


nSpeed = the velocity at which a startup is able to build and release new features.

To be clear, the nSpeed estimates below are my personal estimations and not scientific fact. However, I hope they illustrate my main point which is software and business complexity severely slow down the rate at which a technical team can release new features. A fact that many non-technical folks find hard to grasp.

Phase 1  Moving from idea to prototype [nSpeed = 1]

The maximum possible nSpeed is during prototype phase. One developer is able to build huge swaths of product at a break neck pace. There is nothing to impede the developer from thinking about and building new features. No users, no maintenance, no sysops, etc. 100% of efforts result in new features.

Phase 2 – Releasing an alpha version to friends and family [nSpeed = 0.75]

The first group to use a software product is usually a small group of friends and family. At this point developers can no longer devote 100% of effort to building new features. They need to start fixing bugs, supporting users and being mindful of not breaking the working product.

Phase 3 – Releasing a beta version to early adopters [nSpeed = 0.5]

During this phase, a user-base will typically grow from tens to hundreds of users. Developers now need to start thinking about building a stabilized production environment. Code needs to become more tightly controlled, testing servers need to be used, more time is taken up by sysops, more bugs are reported and more support requests are initiated.

Phase 4 – Releasing version v1.0 to the general public [nSpeed = 0.25]

With successful user adoption comes many challenges. Developers need to start coding with “scale” in mind. They need start adding things like job queuing, asynchronous code, load balancing, database sharding and other scaling related sub systems. From this point forward all new code needs to work within the context of a highly distributed architecture. Also, business overhead increases during this phase i.e more product meetings etc.

Phase 5 – 1+ year after releasing V1.0 [nSpeed = 0.125]

After 1+ year, a codebase can grow to 100k+ lines of code. Testing and deployment procedures are now much more complex. There are hundreds of bugs in the backlog. Support systems have now taken on their own life. Systems operations is a full time occupation. Adding new code now requires an unprecedented amount of time consuming forethought, discussion and attention to detail.

 Phase 6 – Becoming a medium to large company – [nSpeed = ?]

A company with 50-100+ employees suffers from all of the above overhead with the additional resistance factor of working with lots of people. What used to be one person’s job now becomes an entire department. Inter-departmental roadblocks, red-tape and meetings slow everyone down massively. The molasses effect is so great, I haven’t even bothered to guess at an nSpeed.

 nSpeed, In Context

Let’s imagine that Mark Zuckerberg was the only developer who ever worked on Facebook. If you think about him as sole developer, moving from one phase to the next, it’s not hard to picture how the nSpeed of each new phase becomes slower. For example, if he had single-handedly worked on the product to get it to phase 5 (with millions of users, a distributed architecture, etc.) it seems highly likely that he would be pushing out new features far slower than during his zero responsibility prototyping phase. I’m going to venture a guess of at least 10x slower.


I think many people understand that it’s much slower to develop within a complex system than it is to develop within a simple one. However, I’m not sure it’s common knowledge just how much slower it can become over time.

If you are a developer, I would be very interested to hear your guess as to what the nSpeeds of phases 1-6 might be.

At the very least, I hope this article helps illustrate why your tech team is gradually getting slower ;)

Check out my tech startup podcast TechZing. Maximise your downtime by listening to us while you code, commute, work-out or do the dishes!


  • Herbrandson says:

    I couldn’t agree with you more. This is something I’ve been thinking about lately, especially in the context of the lean startup movement. There are many things that I love about getting an MVP out the door and getting to the user feedback phase as quickly as possible. The value of that approach is pretty clear and something every startup should put serious thought into.

    However, it seems that every approach has its tradeoffs. As you pointed out, phase 1 is the easiest time to move quickly and add new features. I would extend that to say that phase 1 is the easiest time to:

    1. design for performance/scaleability
    2. architect extensible/flexible framework(s)
    3. create the vibe/feel of your app (or really design UX in general)
    4. get all the little stuff right (the stuff that makes users really love an app)

    I even wonder if the degree to which these items are addressed before that initial launch don’t set a sort of scale factor on the next couple of phases nSpeed numbers.

    Don’t get me wrong. I’m not advocating a return to classical waterfall or “big upfront design”. However, I do feel like we as people tend to go from one extreme to the other. I love the idea of an MVP and early user feedback, but I also think it needs to be tempered with some thought about what tradeoffs are being made. I agree with your conclusion and would take it even further. The effect of complexity/scale on the ability to innovate is exponential. And, the easiest time to mitigate complexity is early on in a project.

    So what does that mean? I’m not 100% sure yet :). Perhaps just that each project needs to be examined and the tradeoffs of early user feedback vs. nSpeed scale factor need to be weighed carefully. I think the right balance will be different for each project and that it’s ok for your project to not have the same fulcrum as others projects.

  • Comments closed