I was talking with a friend of mine the other day about this one app he’s building for himself. He was really excited pitching me the idea, talking about screens and features and possibilities. You know, all the good stuff.

And I’ll be honest with you, he got me excited about the app too. Why? For starters, he had a pretty good idea that targeted a niche and solved a problem (essential for app development). Second and most important, he was really passionate about his ideas and the good that could come out of his work; and that was what got the little maker in me to fire up.

I asked him to send me the details for the project, and he did the very next day. I read through them carefully and just as I expected, it was really good. It just had one problem: Too many features.

Now now… I know what you’re going to say, how can having too many features be a bad thing? (Or maybe you didn’t say that, but work with me for a second here)

Well, I’m about to propose to you the following:

You can make your application better by having it do less things.

Interested in getting to know how, why or what I’ve been drinking? *cough* coffee *cough* Then buckle up soldier, we’re going for a ride:

Author’s Note: The ideas and tips that are presented in this post are highly influenced by the work done by 37signals (now basecamp) and specially their bestselling books Getting Real and Rework. For a deeper analysis of these methods I highly recommend reading their books and following their blog at Signal v. Noise.

Taking a look at our application… plan.

Don’t worry, it’s not really this complicated.

For the sake of this argument, let’s take a look at a sample application development plan. (More like a features list in this case) You know what? Let’s have some fun with this and take one of my earlier drafts:

Car Pooling App

Purpose: Provide a way to manage the car pooling routes to the office for the people working at Sample Company.

Feature list:

  1. Login/Account Creation.
  2. Setting up Routes.
  3. Contact Information
  4. Display Available Routes.
  5. Request a Route.
  6. Sign up for a Route.
  7. Automatically update Route status.
  8. Google Maps integration.
  9. One Touch Facebook Login
  10. Google Calendar Integration

Doesn’t seem too extreme does it? In fact, it’s a pretty good and solid application to develop, If I may say so myself: It attacks a known problem, for a specific niche of people, and it does so in a way that shows it is considering the needs of their users and facilitating them to work with it as much as possible.

The only problem I see is that most of the features present are not essential for the application, but instead serve to enhance its core; which is defined only by a handful of the members in the previous list.

Sure, having reminders show up on my google calendar is an extremely useful feature, but not one that my app truly needs in order to function. Having access to google maps without having to exit my current train of thought is very convenient, but not necessary for me to actually use the application.

Why is this important?

When you’re starting to develop an application it is easy to get lost in the details, in the extra functionalities, in the integrations and the commodities. It is so easy in fact that you can sometimes forget that these features need a solid center to be based on to even contribute to your application.

How do you define this center? We start by saying no.

Just Say No

You get a No! And you get a No! Everyone gets a No!

Start by putting yourself on the role of a stakeholder: You are now Johnny Appleseed, chief executive at your own project. Give yourself the full package: fancy suit, a portfolio and an undying love for efficient budgets.

Now imagine you’ve been tasked with just one goal: Push the first version of the application in the most efficient, fast and cost reduced way. You come across the list of features that your programming team (in this case yourself) has given you and you quickly realize that their scopes are way over your deadlines in every single way.

So you come up with a solution: Say no to every single feature except one.

  1. Login/Account Creation. – NO
  2. Setting up Routes. – NO
  3. Contact Information. – NO
  4. Display available Routes. – NO
  5. Request a Route. – NO
  6. Sign up for a Route. – NO
  7. Automatically update Route status. – NO
  8. Google Maps integration. – NO
  9. One Touch Facebook Login. – NO
  10. Google Calendar Integration. – NO

You then gather up your group of programmers and designers and show them this list. And ask them to do one thing:

Fight for one single feature that truly defines what the application is about.

Working with a feature budget

The example featured (haha) above may seem a little bit harsh, but it is actually a method that forces you to focus on what really matters: If you could only build a single feature of your application, which one would it be?

It is important to include the full team on this discussion (unless it’s just you, in which case I fully encourage you to include all of you in it) as everyone is sure to have an opinion as to what is the single most relevant feature.

Some things to keep in mind while you’re doing this discussion:

  1. Focus on the product: Don’t take anybody’s arguments personally. The discussion should be geared towards creating the best possible product and it is important that everybody understands that.
  2. Argument in favor of your feature: Why would it work? Why would the app not have meaning if it is not included? Remember you’re raising a champion amongst features, the best of the best. Try to focus your argument on the positive aspects of it and abstain from bashing other people’s ideas.
  3. Propose alternatives: Maybe you can place a phone number instead of having users register manually, maybe you can work with a table full of data instead of a google maps integration, maybe you just need phone numbers and names instead of a fully fledged user system.
  4. Compromise: Sometimes in this argument you’ll see that you actually do need 2 features instead of one. Or perhaps that you can take parts of 3 different features and merge them into a single super feature.

On our little carpooling application, I’ll make an argument that the most important feature is the Contact Information. Why? Because if I just had access to a list of contacts that I knew were interested on car pooling to work, I could do a few phone calls and eventually (albeit quite painfully) end up with a car pooling route to work.

Somebody else could argue that the most important feature is Displaying the Available Routes, and argument that if you knew which routes are available and which one works better for you, you could eventually network your way to a car pooling route (these people are, after all, your acquaintances from work).

So I say we compromise and instead Display the Available Routes, while also including the phone number and name of the person offering the route. Let’s also compromise to leave a phone number for people who want to add their route to our app

Our Application plan would end up looking like this:


  1. Display Available Routes with contact information.
  2. Phone number to call for adding Routes with contact information.

Maybe Later:

  1. Login/Account Creation.
  2. Setting up Routes.
  3. Request a Route.
  4. Sign up for a Route.
  5. Automatically update Route status.
  6. Google Maps integration.
  7. One Touch Facebook Login
  8. Google Calendar Integration

Now it won’t be the most comfortable application to use, I accept that. But it can be used very simply, and it will get you results. And that is all we truly care about this early in our application.

So far all my reasons for following this guide have been geared towards focusing on what’s really essential to our application. And that’s all good and nice, but I can already hear even the developer in me saying: “Yeah well mate, I can just work a little harder and squeeze a few more features in version one”.

And that is a really good thing, it is our drive as makers to try to make the very best product we can achieve. It is only through striving for perfection that we are able to even get close to it.

But before you start typing in those lines of code or finish booting up Illustrator, let’s just talk about what that Tiny little feature is bringing with itself to the table.

The true cost of adding “just one more little thing”

Don’t know about you, but I don’t really see loads of cash in there.

This is what is really needed to achieve the first version of our app:

  1. Display Available Routes with contact information.
    1. Database with Route and Contact information (Can be added manually).
    2. View to display said data.
  2. Phone number to call for adding Routes with contact information.
    1. Single line of text somewhere prompting to call if they want to add a route.

For comparison let’s see the work that is truly necessary to add one of the most common features in an application: Users.

  1. Users
    1. Database for holding user information.
    2. Re-design our Routes view to work with users instead of Contact info.
    3. View for a single user.
    4. Maintaining sessions.
    5. Security and Authentication.
    6. User types.
    7. Permits.

It could be argued that some of these sub-features are not really necessary for building out a successful user system, but it could also be argued that I am missing some very important sub-features that could further optimize the way users work in our application (adding profile pictures and descriptions, for example).

What is really important to see here is the reality of how much work is packed in that one little feature’s seemingly simple and easy implementation. Adding users is providing more than twice the complexity than our original application even had.

This doesn’t mean we shouldn’t ever implement users into our application. The feature itself is in fact a wonderful idea that (executed properly) could provide a much more personalized and engaging experience for the real people using our application. We just need to be sure that adding it to our app will be worth it.

And how do we make sure that we even need to add more features? We make sure our app works in the real world.

Get it out there.

Your app will never be perfect.

There will always be this one more little thing you’ll want to add to it, just a little more tweaking you’ll want to do, just one more revision you want to do on the design.

This is your baby, you’ve been working on it for a while, nobody knows it quite like you, and you’re worried nobody will see its beauty the same way you do. You’re worried they won’t understand it.

Trust me, I’ve been there, I know how difficult it is to let go. And I’m here to tell you it’s ok. You poured your hearth and soul into your work and it’s ok to be proud and protective of it.

But just like a mama bird with her children, you have to let your app try it’s luck out there in the real world. And here’s why:

You won’t know it works until it’s been properly tested by real people.

You can run all the testing in the world you want, and by all means do so if you can afford to. But it will still never compare to the reality of having your app face against real people trying to do real things. So make sure there are ways to let them give you feedback on your creation.

They are the ones who are going to tell you what your app truly needs, the ones who will find the bugs for you, the ones who will be asking for more.

You can always add more features later, clean up the interface, improve the user experience. But there will never be a better moment to start getting real input about your application than now.

By all means, don’t release something you know is broken. Try to make the best out of every feature you DO include in your application. Truly make them shine. But as soon as that’s done, start releasing, you can always improve later.

On that topic.

Knowing what to work on next

We’re up all night to get feedback

Once your app is there, make sure you listen to what your users have to say about it. But don’t worry too much.

If you already have a plan for features that you’re intending on building, by all means follow that, just make sure you give all new feature additions the same treatment you did for the first.

  1. Start by saying no to all of them.
  2. Make your features fight to be included by proving they’re valuable.
  3. If there are no features deemed worthy, just don’t add them

Other than that, just keep your eyes and ears open, listen to your users. Don’t write down their concerns or petitions, but pay attention to them. Little by little the things that your community truly wants will become evident to you. How so? Your users will keep reminding you.

When is it be time to actually consider a request? When it’s been said to you enough that you don’t have to try hard to remember it.

One exception: If you ever come across a request that makes you wonder “How come we didn’t think of this first?” perhaps it’s time to listen to it.

Closing thoughts

My friend and I followed this same process, the result being something that looked like this (just obviously with a different set of features):


  1. Display Available Routes with contact information.
  2. Phone number to call for adding Routes with contact information.


  1. Users.
  2. Setting up Routes.
  3. Updating Route Status (Available seats, etc.)

Maybe Later:

  1. Signing up users to routes.
  2. Request a Route.
  3. Automatically update Route status.
  4. Google Maps integration.
  5. One Touch Facebook Login
  6. Google Calendar Integration

It cut down the list of planned features to around half, and prioritized them for development, something which has aided us greatly while working on actually building it.

Of course this exercise is the result of the opinion of a single person, and I would love to hear what you have to say about it and your own experiences dealing with app development.


My name’s Orlando Paredes Hamsho. I’m a 25-year-old Web Developer living (mostly) in Guadalajara, Mexico; albeit I intend to move pretty soon. Apparently, I also run a blog now, and have been doing so for a while.

Write A Comment