Do You Even Know What You’re Building?


What are you building? What are you trying to accomplish? What do you want your system to do?

These are all excellent questions.

Whether you’re looking to build a small system with fewer, simpler features or a large system with more complex features, you should really know what you’re getting yourself into before you start. That goes for clients and developers and designers alike.

What kind of system are you building?

Well, generally speaking, you’re either building a small or large system. So what’s the difference?

Small System

  • Takes only a few weeks of work
  • Has a smaller budget
  • Has a singular function or a only a few well-done functions
  • big picture

    Take Tinder, for example. Yep. Tinder.

    When it comes down to it, Tinder only utilizes a handful of features, such as swiping, reporting, messaging, user profiles, and sales ads. It’s nothing terribly complicated and generally would not take an absurd amount of time to design.

    Large System

  • Takes several months of work
  • Requires a hefty budget
  • Has multiple functions
  • Requires process and form management and building
  • Larger apps, like Mailchimp, require more time to build, provide the customer with an extensive amount of features, and require a more complex design.

    More features, please.

    I’m sure you’ve had a client add on features at the last minute or suggest new features at some point. But the reality is the more features you add, the more complex the design. But it can’t be that complicated, right?

    Well, no.

    Think about it like this: If you add a feature, any feature, you then have to change every other feature you’ve already designed in order to integrate the new feature, exponentially raising the complexity of the design and the entire system.

    Not only are you making it more complex, you’re also increasing testing time and increasing the number or potential issues. More features, more bugs, more complicated.

    big picture

    Don’t speak in broad strokes.

    Simply put: be specific and detailed.

    If you’re a developer or designer, you certainly appreciate when a client is as direct and detailed as possible.

    But if you’re a business owner or client working with a developer or designer, you need to understand that generalizations just aren’t going to cut it. DON’T OVERGENERALIZE.

    The last thing a designer or developer wants to hear is a broad, nonspecific statement, such as “It needs the utmost level of security”.

    What does that even mean? Does the client know how much it costs to provide the “utmost level of security”? Probably not, because it’s probably 5x the original budget. What the client needs is the security they can afford within the budget.

    So speaking about specific security measures is always helpful (and respectful!) to a developer. Honestly, they can build great systems, but they can’t read your mind.

    big picture

    “But the app should…?”

    Honestly, it really doesn’t matter what your app should do, it only matters what it does.

    In design and development, there is only what your product does or does not do. Try not to get caught up in the “shoulds” when building a system. Be realistic with yourself and with your clients. Make sure to explain how the design works, what the features are, and what the features do.

    Even worse, try to avoid the comparison “should”. You know, “It should work like Twitter or Facebook.”

    No, it shouldn’t. It’s very likely that a client, unless extremely familiar with design and development, doesn’t know how much time, effort, and money it takes to make large systems work. Only have a $7,000 budget? Well then sorry, but you’re not getting a system that works like Facebook or Google. It’s just unrealistic.

    One way to avoid the “should” issue is to properly scope your project from the beginning. Trust me, it’s worth it.

    So what is the end product?

    Ultimately, the system will do what it does and that’s it. Remember, don’t get caught up in what they system can do, but recognize what it actually does. It’s better for you and your clients.


    Jason Long

    Jason Long is the founder and CEO of Brainleaf and an Information Architect and Managing Partner at CodeWright. A self-professed serial entrepreneur, he is always interested in new businesses, new ideas, and new ways to change the world. He has over 15 years of experience in design and development and has served in a variety of different roles ranging from designer to Information Architect to CEO. He spends most of his time focusing on the build and development of new ventures while trying to travel the world.