You’ve saved up and got some funding for your app. Now can we jump into picking a software team? Not yet.

Something that is important to understand when building software is that it is not a linear process. You can’t expect to go from A to B to C without having to adjust, pivot, and question your own sanity. Maybe your clients are not liking the platform (or some of it’s features) as much as you had anticipated, maybe you are attracting people from a different target market and need to adapt your branding and marketing, or maybe you thought of a different idea that will be much more valuable and you need to pivot.

Whatever the case may be, it would be to great advantage to you to pick a software company that is able to communicate clearly and adapt quickly.

Building software is not a linear process

The A,B, Cs of communication

You’re probably thinking “DUH! of course communication is important. It’s obvious”. Well, it’s not as obvious as you may think. I’ve had several clients tell me that once their initial requirement gathering session was complete, their software company didn’t speak to them until their app was complete. ONE YEAR LATER. On the other hand, I’ve had colleagues tell me that their clients email them every day, sometimes multiple times a day for months.

So what is the right amount of communication to have with your software team? We have found that setting up bi-weekly calls were we showcase what we’ve done for that 2 week period and weekly budget updates keeps our clients informed and allows them to ask for any changes and iterate on the product while we’re building it as opposed to once it’s “done” (because software is never done, let’s be honest here)

Now, as your development team progresses through the app there are bound to be bugs. Bugs in software are inevitable. How you report this bug will make a difference on whether the developer spends an extra hour or so trying to debug and reproduce the bug. My colleague, Ryan Fairweather, created this graphic to illustrate how to report a bug that will help your software team fix it sooner rather than later.

Iteration: The sooner the better

Let’s look at two examples:

Jenny has hired a software development firm to build a meditation app

Suzy has hired a different software development firm to also build a meditation app

Jenny and Suzy do not know each other.

Jenny’s software development firm tells her that they are going to build her app for $50,000 in 3 months while Suzy’s software development firm tells her that they are going to build her app for $25,000 in 6 weeks but that she will have to drastically cut down the number of features that she wants and she has to ruthlessly prioritize which features she wants to have in this first cut.

6 weeks come and go and Suzy already has the first iteration of her app and is now able to take it to market and get direct feedback from her customer base. Jenny is getting consistent updates about her app from her team and is excited about progress.. she’s heard rumblings about Suzy’s app but she’s not worried about it.

Having secured an additional $25,000 from pitch competitions, grants, and the occasional user that has subscribed to her app, Suzy asks her development team to continue working on the app and has given them new feature requests (that came directly from her users) and has asked them to take out some features that her users didn’t really need/liked. She also asked them to update some of the colors and polish the site

Another 6 weeks come and go and Suzy’s new iteration of her app comes out and her subscribed user count increases. She secures some more funding and starts the process again with new feedback. Jenny finally has the first cut of her app. She takes it to market and realizes that: her target market don’t like/need most of the features in her app and that Suzy’s app has gotten the majority of their target market by now and is better known. Now she needs to play catch up.

This is a trivial example to illustrate a very important point: Going to market as soon as you can and getting feedback from your users is crucial. In the long run, it will help you save money by not spending money on features your users will not use and it will help you course correct sooner rather than later.