6uhhe19yg7So you’re setting out to build a system. It’s your baby. It’s your dream. It’s everything you’ve been hoping for.

But do you actually know what you’re building? Do you know what you’re getting yourself into? Do you know what it takes to build this system?

Well, first, you have to decide out what kind of system you’re building.

It boils down to two options: a large or small system. Simple enough, right?

Well, let’s break it down.

Small System

  • Takes less time to build out – maybe only a few weeks.
  • Easier on your wallet
  • Has one specific function or just a few well-functioning functions

Large System

  • Takes more time to build out – possibly up to several months
  • Your wallet will take a harder hit
  • Has several functions and is typically more complex

Features

mbp-new.pngSome systems require only a few, some require a more complex tier of features. So essentially, the more numerous and complex the features, the more complicated the buildout phase.

So what happens when a client wants to add on a feature or two last minute? Well, frankly, it gets a little complicated. (More than a little complicated actually.)

If you add in a new feature, you have to adjust every other existing feature to accommodate the function of the new one. This makes the process infinitely more complicated and complex – including the design of the entire system.

Once a new feature is added, it has to be tested. Sounds pretty straightforward, but more testing equals more time. Not only will it take more time to test, you have just increased the amount of potential bugs that occur.

Don’t overgeneralize.

If you want a feature to do something, it has to do a specific something. And if it has to do a specific something, you have to be specific in asking for it.

Basically, be detailed. Be direct.

Broad, nondescript requests for new features aren’t going to make the buildout process any easier. In fact, it might make it worse. Nothing is more frustrating to a developer or designer than hearing: “I want it to have the highest level of security possible.”

Should.

Startup Stock PhotosA developer’s or designer’s least favorite word is “should”. The app should do this or it should do that.

Honestly, the app does what it does and doesn’t do what it doesn’t do. If you want an app that “should” work like Facebook or “should” work like Instagram, just use Facebook or Instagram.

Don’t get caught up in what the app should or should not do, but focus on what the app does, how the features work, and how intuitive the design is. After all, a well-designed and intuitive smaller app is better than a larger app that is poorly designed with a ton of ill-functioning features.

So where does that leave you?

Well, it leaves you with an app. An app that does what it does. Try not to get caught up in what you think the app should do, but try focusing on what it actually does. It’s more beneficial for you in the long run.