The 4 Ego Traps That Sink Rockstar Developers

You just launched your first app. Don’t blow it by thinking like a rockstar.

The 4 Ego Traps That Sink Rockstar Developers

When a team of indie developers begin building a product, there’s a high: You just build, build, build. You’ve already validated your idea with real live people, they love it, and your team’s enthusiastic. The motivation is contagious. You feel awesome.


But once you launch, things change radically. It’s not all about features and projections anymore. If you throw a party after you ship and act like the world is your oyster, you’re probably on the road to failure.

There isn’t any protocol for the hazardous post-launch stage, so I’ll attempt to outline one based on some wise words that my team followed after we launched our new mobile app Furnish for iOS (more about the app later). Credit goes to Marc Hemeon of YouTube and Kevin Hale of Wufoo, who inspired the following ideas during their talks at the Warm Gun Conference on Measurable Design late last year. Everyone creating products should listen to them; here’s my version of a study guide, adapted for the post-launch crunch time.

0) Rockstars Can’t Make Time For Everything Else

“Rockstar,” “ninja,” and “chief hacker” are some of the descriptives that get thrown around startups today, and it’s tempting to self-apply these labels. But even if you’re a talented developer and your product’s great, indulging this way is a surefire way to blow it post-launch, when you realize what the daily grind is really all about. (Hint: It’s not about you.)

Instead of spending all your time on features, your post-launch team schedule usually ends up looking something like this:

After launch, don’t be tempted to think you’re too good to be involved in any aspect of the business. You built the product: It’s your responsibility to support it, cater to your users, and keep the project viable. The team behind our app comprises three married guys with kids and day jobs, so we know it’s a struggle to spend your free time on something other than “killer” new features. But we still split up customer service requests evenly across the team, and handle our own human-resource type activity instead of forcing one member of the team to shoulder all the drudgery.

1) Rockstars Get Too Much Funding

Premature funding is an epidemic. If you can help it, don’t get funding at the outset. Getting pre-launch funding is like asking people to sponsor you for an Olympic bid before you’ve determined which event to compete in.


Remember, getting funded doesn’t mean you’ve won anything. The goal isn’t securing investment. It’s securing users’ loyalty–by the thousands. Hunt for funding only when you need to rapidly scale a product with proven traction. If your product hasn’t found traction, keep veering around until you do. Don’t waste other people’s money while you do it.

The justification for funding is almost always more or better features. These are almost always features the application doesn’t need yet. Our prototype was an extremely basic augmented reality app for furniture shoppers, and it was missing a lot of things that a more ambitious developer might have considered “essential.”

In fact, the only thing the app really did at launch was display a 3-D model of a given piece of Ikea furniture overlaid on the camera view, to show how the piece might look in your home. We even dashed off a name, calling the app “Ikea Now” until we had time later to consider the brand further and come up with a better one. Now it’s called Furnish. (At right, Furnish shows how a chair will look in your home.)

This isn’t the same as saying you need a “minimum viable product”; everyone knows that. Really, you need a “minimum viable experiment.” We wanted to test that single hypothesis: Would people really use this tool to shop for furniture? Finding out the real answer means maximizing the integrity of the data. If you pollute the app with too many fancy features or variants on tasks, you’re introducing variables that obscure the results of your experiment. You certainly don’t need to borrow money (or give away equity) to make this possible.

2) Rockstars Don’t Validate

Building software is an exercise in empathy. If you can put aside your rockstar mentality, you’ll be more inclined to be attentive to the customer’s needs. Your customers know more than you about what will succeed, and the sooner you realize that, the sooner you’ll have a growing pool of users.

By day, I’m the senior creative director at Live Nation Labs. Creating software and an event (or media) are similar: You’re ultimately building something for a common denominator, which is human enjoyment.


Humility leads to an earnest and perpetual desire to understand the people who want your app, and thus better understand what they enjoy. You should be hungry to support and understand them.

Before we started Furnish, I asked people through my social networks whether an application like this would be even useful. I also used an iPhone application called Thumb, which lets you crowd-source opinion questions, to answer basic questions about how people shopped for furniture. Thumb is an invaluable utility for entrepreneurs who want to do impromptu focus groups. The data I collected gave me a clear answer: Hell yes, people want this app!

We weren’t afraid to launch a free iOS app with barebones functionality, even if it wasn’t our proudest work. Our first prototype was a hack; it took less than four weeks to build. We spent the first week and a half building the application then took the next two weeks creating 3-D models of 40 of the most popular Ikea furniture items.

In the first version, the user couldn’t save an image of a room with virtual furniture in it; there was no landscape view; there was a limited number of furniture pieces; and since the app had no backend, all the 3-D furniture models were packaged in a big fat app download. We had to keep our egos in check and proceed with the experiment anyway, knowing that we could polish the experience and the feature set later, if users’ interest level warranted it.

3) Rockstars Can’t Take Competition

Lots of entrepreneurs are so protective of their ideas that they refuse to collect information from customers from fear of copying their idea. But that also stops them from researching similar apps.


Before my team began building Furnish, we looked for other apps in the similar vein. We found a couple of comparable apps where the execution wasn’t great, and they didn’t have a lot of reviews, so we figured we had found a space in the market.

When we published Ikea Now to the App Store, we wanted to make sure it stood out. (We weren’t sponsored by the retail giant, just three nerds who wanted to solve a universal problem with a simple solution.) Instead of trying to dominate a popular app category like “Lifestyle,” we opted to have “Catalogs” as our primary category. It was evident that catalogs had far fewer great looking apps. When our app finally went live, Apple then featured our app in the Catalogs homepage.

Proof Humility Gets You Growth

In a matter of weeks, Ikea Now had over 70,000 users in more than 100 countries. It became clear that our hypothesis–people could use augmented reality to shop for furniture–is overwhelmingly validated. That’s when we decided to spend more energy improving the app and the brand, switching the name to Furnish and improving the efficiency of the main task. You can see our traffic charts below; each of the orange spikes is related to people looking for furniture apps on weekends.

When I compare our “humble” approach with Furnish to my first startup, the results speak for themselves. My first company was a CMS platform that sourced local deals into third-party party apps; we worked our asses off and made 500 partner deals in eight weeks. We pivoted the product into a mobile proximity-based professional networking app called Mingle, secured a small six-figure seed round about a year ago, and figured we were hotshots. Mingle grew to 35,000 users across 70 countries, but it felt hard-fought. After just a few months of working on Furnish, our user-focussed approach has gotten us three times the users in one-third the time, so we’re shutting Mingle down.

Once you realize that you’re in the business of serving your users, you’ll see how the rockstar metaphor is all wrong. If anything, like Mark Hemeon says, we’re drug dealers. Dopamine dealers, to be exact. Psychology and behavior principles go a long way to understanding how apps can participate in the brain’s rewards system, but you don’t need to be a neuroscientist to understand the underlying principle: Build products that make people’s lives easier and more fun. Your success boils down to how much your app makes a user’s lips curl–not how badass you feel building it.

Andy Kim founded Furnish with tech veterans William Chu and Austin Evelo. Andy serves as the Senior Creative Director at Live Nation Labs. He has 13 years of interactive product experience specializing in product development, interaction design, and front-end programming. He is also cofounder of, a proximity-based mobile professional social network which now has users from over 100 countries.


[Image: Flickr user Olly Coffey]