RWDevCon 2016 Inspiration Talk – The Power of Small by Cesare Rocchi

While we always seem to be under tremendous pressure to grow our companies larger and larger, being a small company gives you many advantages. Cesare explores these advantages in this inspirational talk.

Note from Ray: At our recent RWDevCon tutorial conference, in addition to hands-on tutorials, we also had a number of “inspiration talks” – non-technical talks with the goal of giving you a new idea, some battle-won advice, and leaving you excited and energized.

We recorded these talks so that you can enjoy them, even if you didn’t get to attend the conference. Here’s our next talk – The Power of Small by Cesare Rocchi – I hope you enjoy!


Grow, grow, grow!


We are surrounded by podcasts, conferences, books, blog posts, all forcing us to grow. Grow our user base, grow the number of downloads of our apps, grow our mailing lists. Always grow!

This is probably propelled by the Silicon Valley movement in which hockey stick growth is a requirement if you want to chase the next round of funding.

We also are used to hearing that size matters.


Even excluding all the nasty interpretations of that, probably you’ll think that the bigger the better. The bigger my team is, the more projects I can take on. The bigger is the market, the bigger is the potential income. I don’t want to even mention the bigger the code base…

It’s all true. Grow, grow, it’s all true. Probably. But is it worth it? Have you ever asked yourself is it worth it to chase something bigger? Do I want to give up the power of small?

Well, in the 70’s IBM was the king – I’d say the emperor of computers. Then out of the blue, two dudes in a garage started small – and you know the rest of the story.

Today I’m going to talk about the power of small. I’m going to show you some example of the advantages of working in a small market with a small team and exploiting the advantages of a small launch.

The Power of Small

Let’s start with the advantages of a small market or niche.


Note it’s pronounced niche, not nitch, because it’s French.

  1. First of all, big companies do not usually care about small markets because there’s not a lot of money to be made there.
  2. Advertisements usually in niche markets are way cheaper and more cost effective.
  3. The third part is there are fewer competitors, so it’s much easier for you to stand out.
  4. The fourth point, probably the most important, is that probably you’ll end up talking to the real customers, experiencing the real problem that your app or product or service is trying to solve, as opposed for example to the enterprise in which you usually talk to the CTO or the marketing manager that represent the people having the real problem.

Here’s a quick example of a small successful market:

Screen Shot 2016-06-27 at 5.30.30 PM

This is Soda Pop Stop. John Nese and his family have been running this business in LA for a long time. They started as a grocery store and now they have a website that sells and ships sodas worldwide. Probably you’ve never heard of this company. We all know that the sodas market is dominated by huge companies that I’m not even going to mention.

But Johnny’s family has been able to carve out a small niche in which people prefer something alternative, I’d say unique, like for example the Werewolf Howling Ginger Beer or the Pumpkin Spice Tonic, which you’ve probably never heard of. That’s fine. Because that’s a nitch or niche?

Audience replies: Niche.

Great. Johnny’s family have been able to run this company for 100 years. Are you seeing the power of small already?

Advantage 1: Moving Faster

Let’s talk about the advantages of a small team. You can move faster.

Screen Shot 2016-06-27 at 5.31.07 PM

Let me tell you a quick story. I joined a startup a few years ago. I was the only mobile developer, front end developer, and the other developers took care of the back end. We used Git but honestly we could have used a shared Dropbox folder because we never had a merge issue, our changes never overlapped, and after years that we both spent in the enterprise and convoluted processes we felt wild and young and free.

Really, I was committing code to the master branch and I felt like this when I did it.


But things changed. The company grew. We had to put in place formal process and documents and agreeing on a time slot for a meeting took longer than the meeting itself.

I could not commit to the master branch anymore unfortunately. You know the drill. You had to branch out, do your thing, run the tests, code review and then merge, and then Q&A, and then staging, and then production.

Don’t get me wrong. I mean, having a process is a great thing, because you have fewer chances to screw up. But it also can enlarge the distance between you building the product and the people using the product.

Advantage 2: Easier Decision Making

Now a small team is a competitive advantage so make the most of it. In a small team for example making decisions is much easier.

Screen Shot 2016-06-27 at 5.31.28 PM

This is a story that Luke Parham, an iOS team member at, told me. He worked at a company. They had an app that allowed to consult used car reports. So instead of going to the dealer you just browse cars in the app.

They had a back end in Java. It was in Struts framework. (I can’t believe I mentioned both Java and Struts at a Mac and iOS friendly conference!)

Now if you look in the dictionary for the definition of “long”, there are a few examples there. One of them is the discussion that you can spark when you ask a bunch of developers, “Should I use vi or Emacs?”

Still in the dictionary, if you look up the definition of endless, one of the examples says, “The discussion that you can spark when somebody in a room full of developer says, ‘We should use a more modern framework for our back end.’”

Now at Luke’s company there were 7 people, 7 developers. It’s an odd number. It should be easy to come up with a majority. 2 wanted to go with Rails, 2 with Django, 1 with node JS, 1 didn’t care, the other one wanted to stick with the old framework. You can image which kind of discussions they had.

At some point somebody started building prototypes trying to show the advantages of a framework over the other. As it happens usually the meeting started with 7 people and after 2 months 20 people were attending the meeting and contributing and discussing and essentially wasting time.

Guess what? In the end they decided to stick to the old framework.

Now who here heard or lived a similar story? I see somebody can relate to this. This is what happens in a big, big team unfortunately.

Advantage 3: Small Launch

Now let’s see the advantages of a small launch.

Imagine you had your idea. You designed it. You built it. You are ready to ship. But at some point one thought, especially if your app has some back end, this thought is going to hit you: “What if it doesn’t scale? What if some famous blogger talks about us and all the customers use our app and hog our servers?”

Have you ever heard something along the lines of this? Yeah.

A few observations.

  1. It’s a very nice to have problem.
  2. It’s probably not going to happen.
  3. Instead of postponing the launch by 6 months because you’ve got to reword all the back end to scale it up, why not just soft launching to friends, to people you trust, to people that you have meet at some conference? Why not just soft launching to some people that drop their email address on the landing page? Why not just testing the ground and see how it goes, instead of getting in a tunnel that is 6 months long.

The Story of Buffer

Take Buffer for example.

Screen Shot 2016-07-04 at 2.14.36 PM

They started with a simple landing page. Buffer if you don’t know is a service that allows you to schedule social media posts. They support Twitter, Facebook, Pinterest, LinkedIn, and so on. They started just with Twitter. They started just with 1 web page that explained the product and they noticed that people clicked.

After a while they added a second page, fake, showing the pricing plans. It was fake and again people were clicking. Bottom line after 7 weeks they build a product just with Twitter and they had the first few paying customers. They did exactly that, start slow.

A small launch can help you in testing the ground, testing the code, testing the design, spotting bugs.


It’s not a new idea at all. Restaurants do soft openings every time to give the stuff a test for example and to spot issues in the menu, typos in the menu for example.


Have you ever watched the Ocean’s Thirteen? A few of you, okay. So no spoilers, but there’s a pretty good scene of a casino doing a soft opening in the movie.

Tips and Tricks

Now let’s see some tricks that you can exploit to stay small and focused.

The first one probably my preferred one is to set a time limit.


Think along the lines of will submit this app in 3 weeks with feature A, B, and C, and that’s it. Or let’s take big app, break it down in 6 milestones, and then finish just the first one and ship it to the store in 3 weeks.

Set a time limit because if you do that … Well, first of all, the end is in sight, so I got to get there and not somewhere unknown. You go with small steps. That helps the morale because you easily notice the progress day by day.

Set a limit on features. I’m sure any of us probably at some point in their career started with an app, big ideas, many features, I’m going to do everything, and then you end up struggling along the way, you are 40% done and you don’t even know if you’re ever going to finish the app.


Why not starting with fewer features? By the way, you don’t even know if all those features are relevant and valuable to your customers. So why not just starting with fewer features and maybe talking to your customers about those features? Much easier.

The third suggestion is break it down.


Try to break it down as much as possible. Now, I am a father, I have a family. I cannot afford anymore 10 hours of uninterrupted work a day. Although sometimes I think if I could have 3 good solid days, but I can’t. But I happen to have on the spot 20 minutes here and there.

Now if I carefully organize my to-do list with small actions easy to chew, then it’s great. What can I do in 20 minutes? Well,

  • I can come up with 3 headlines for the landing page.
  • I can draft a welcome email message on my service.
  • I can write a test for the logging procedure.
  • There’s so many things that I can do in this on the spot 20 minutes that I happen to have.

    Summing up here is the list of my suggestions.

  • Set a time limit
  • Set a limit on features and
  • Break it down as much as possible.
  • Real World Example: Base Camp

    Let’s see a few examples in the world of software. You probably are familiar with Basecamp.

    Screen Shot 2016-07-04 at 9.45.25 PM

    They’re not a publicly traded company so they are not forced to share numbers at all. Pretty good place to be. But we can make an educated guess that they have around 10 million users.

    Do you want to venture and answer to the question how many people are working at Basecamp? 50. That’s CEO, CTO, designers, developers, janitors, everybody. 50 people doing everything.

    There’s a lot of advantages in this situation. They’re also bootstrapped. First of all, they’ve been able to grow the company culture slowly. No revolutions. Also that means that people tend to leave the company less often.

    Also they are careful in hiring because you know in this case hiring means cutting a part of your check every month to pay someone else to work for the company. But it’s been working great for them so far because they’ve been around for 12 or 13 years as far as I remember.

    Real World Example: Quip

    Another example is Quip.

    Screen Shot 2016-07-04 at 9.45.08 PM

    This is a VC funded company in the Valley so they have money, but probably they don’t spend it on developers because they have an app that is compatible with the Mac, Windows, Linux, Android tablets, iPhone, iPad, Apple watch. And it’s just 13 people, including CEO and CTO which probably are not going to code every single day.

    They have a small team, tight-knit, super effective communication and they are forced to prioritize. This is the result and it’s great.

    Real World Example: Desk PM

    There’s also solo developers. Have you ever heard of the app Desk PM?

    Screen Shot 2016-07-04 at 9.47.38 PM

    It’s made by John Saddington. Just one guy. He won the Apple award 2 years in a row. It’s a blogging application. I’m sure I can say there’s no shortage of blogging applications in the App Store and yet he’s been so successful.

    Now when you’re solo, again, there are advantages. Like you can choose your own pace. It took John 13 years to build the app.

    You can experiment and you can decide where do you want to go. Also, how to reinvest your income. For example, there’s a pretty famous blog post in which he describes how he dropped either 9 or 10k as sponsorship on Daring Fireball and it was totally worth it.

    Where To Go From Here?

    Summing up, being small has advantages. So being bigger isn’t always the best option.

  • You can move faster.
  • You can experiment more.
  • You get to choose your own pace.
  • I’d like to close the presentation with a Chinese proverb that really distills my message.

    “It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.”

    Now, what is your next small step?


    Note from Ray: Hopefully after this talk, your next step is to sign up for RWDevCon 2017! :] We’ve sold out for the past two years so don’t miss your chance.