When we won our second hackathon for building another mobile app in a record 2 day time frame, people asked, “How are you guys so fast?”

I’ve thought about that a lot. There are several reasons why and I’d like to cover them in a this post. (Sidenote: You can also watch the short film about our journey through a hackathon.)

Understanding the Problem Makes Building the Solution Easy

This is THE biggest factor in our speed.

The reason we were so fast in the hackathons and won those hackathons was because we were building apps based on our own ideas.

Therefore, we completely understood the problem we were trying to solve. With that understanding, we were able to execute swiftly and confidently. The confidence definitely came through in our product demos.

The problem with a lot of consulting companies is they don’t take the time to understand what the problem is their solving.

Based on conversations with clients, I know that many of my peers don’t take the time to fully understand the problem.

They are more concerned with explaining how smart and cool they are or getting a deposit on the project and figuring it out as it goes along.

From our initial consultation, we’re ready to work. We like to hit the ground running. Therefore, we need to get as much information as we can so we can build the right solution.

Is every client as ready as they should be? No. Those that are definitely see an extra boost of speed in our delivery.

Know Your Tools and Clients Well

Tools are necessary in any trade. App building is no different. The key is to learn how to best use your tools.

We embrace tools that make life easier and faster. If a tool can give you even just a little speed boost, compounded over time that boost will make a huge difference.

Whether it’s our designer’s use of the Adobe Creative Cloud Suite or my use of Xcode, the key is to make use of the advancements the toolmakers build. The toolmakers know that their tool has to make life easier for you or you won’t use it. Therefore, they put a lot of time and effort into new features to help you.

Same goes for the Software Development Kits (SDKs) you use for the various platforms. If the SDK introduces a new way to do something, then use it.

I know some clients will say, “We need to support an older version of the SDK.” I’ll come back with, “Why not use the latest?” Their response, “We think some of our users may be on the earlier SDK still.” To which I ask, “Would you rather all users be mad at your delay in delivering your first version and/or lack of new features just so you can pacify some of them? I would much rather get to market faster, cheaper with a non-dated solution that excludes some users vs moving slower, spending more money on a solution for everyone that is dated the moment it’s released.”

The great thing about users is they’re always upgrading. In the mobile space, every 2 years or sooner, they get upgraded. In the web app space, browsers are easy to install and switching between them is a breeze.

Again, the faster you get a solution out there, the more reason you give users to upgrade if they haven’t. If they really want those new features you provide, they’ll find a way to make it work. The key though is making sure you give them something worth fighting for.

Know Your Work And Yourself Well

I’ve always had great spatial memory when it comes to code.

Ever since I started coding, I’ve had the ability to store the mapping of code in my head vs the code itself. This is vitally important.

Knowing exactly where I first used a MapView, for instance, allows me to automatically know where to go to find sample MapView code.

I don’t have to memorize method syntax or properties, I can instead leave free space in my mind to ponder the problem I’m trying to solve.

Eventually, as I use bits of code enough, muscle/procedural memory will kick in and memorize it without me having to waste any brain cells on the act of memorizing. This allows me to be very fast in my coding because I know where to look for answers in prior work vs having to reread documentation every time, plus my freer mind ponders problems at all hours and gets answers at the strangest times.

I know how humans think when they’re problem solving. I know this because I love to solve problems.

There’s a thrill in learning something new. However, where I think many go wrong is they like that feeling too much. This causes them to use a new attack with every problem to feel that thrill versus falling back on code they’ve already written to solve a similar problem.

This slows many developers down unknowingly. They think the thrill means they’re doing great, when in reality they’re not.

Speedy, But Not Reckless

I don’t want you to think that we place precedence on speed above all else. It’s actually the opposite.

Because we optimize our workflows so well for speed, that leaves us time to ponder and work on things most places don’t.

Even in the hackathons we won, we had time to experiment and try new things because we get our basic app up so quickly.

The hardest part of being fast at what you do is when you have outside dependencies. I often tell clients, “You’ll be our biggest bottleneck.” They laugh, but I don’t. I’m serious and they soon realize it.

I wish everyone could experience our speed, but unfortunately it’s not for everyone.

For some of you, it’ll break you. It’ll expose flaws so huge in your company that you’ll limp away in pain. Sorry, but the truth hurts.

However, if you do know what you want and you are really ready to build something, we’ll be a breath of fresh air.

Our clients who are prepared fall in love with our speed and efficiency.

We love what we do and I hope we get a chance to work together so you can experience both our speed and efficiency.