In the TV show "Naked and Afraid" contestants are sent out to survive for 21 days in the wilderness without any protection (clothing) or help. Although I have no desire to walk around naked in the cold, the show inspired me, a smart but lapsed software engineer,to see if it was possible to create a mobile application that could run on both iOS and Android devices by myself without any help.
Why attempt this? Why invest the time and effort?
When it comes to software development, there is an inherent tension between advising and doing. I have come to believe that when it comes to software development specifically the more advising you do, the less you know what you are doing.
If you, like me, spend time evaluating and investing in early stage growth companies, then you know that most of the important early company decisions center around development. But, even if you have an engineering or technology background, after a certain amount of time of not "doing it" directly, it becomes harder to separate the truth from the noise. Over the last few years, I have heard many suggested approaches to app development and thought I should do this myself if I want to maintain credibility with founders and investors. Time to see how quickly I could learn and build rather than hire and direct or, more recently, invest and advise. Hopefully emerging with a more enlightened view that will help guide me in the future.
For this challenge I wanted to solve a reasonably complex problem that no other application currently solved. So I picked an issue that is limited in its total audience but as an avid golfer, I had the desire to solve. For those of you who are not golfers you might not have heard of golf "handicaps" but they are an integral part of how millions of golfers play and compete each weekend. Their purpose is to allow golfers of all levels of ability to play competitive matches against each other. A golf "handicap" is established by evaluating a golfer's scoring history, the difficulty of the courses that they have played and the difficulty of the course that is about to be played.
Unfortunately knowing your actual handicap at any point in time is not so straight forward. This is despite most private golf clubs subscribing to services that generate the handicaps. I wanted to create an app that would make knowing your (and your playing partners) handicaps for any course that you are about to play to be as easy as possible. The mobile phone is a great tool because you need to access multiple data sources and use geo location to place a golfer on a golf course.
The result of my technology walkabout is the app: GolfWire. It is available in both the Apple Store and Google Play Store. Please check it out.
The Process
Although this was a solo effort, I was never really alone. Unlike "Naked and Afraid", I did not limit myself to just two outside resources. Stack Overflow, GitHub, YouTube and Google were critical resources for my education, decision making and problem solving. With the above resources, I reviewed and selected a technology stack and started the process of designing, building, testing and ultimately deploying a "hybrid" app. This allowed me to build once and deploy across both platforms but still have a quality user experience. I had heard others argue that you "have" to build specifically for each platform to have a quality result but I don't believe that is true anymore. The components and frameworks available really do offer a quality user experience on modern mobile phones.
I quickly picked up Javascript, HTML, CSS, SASS, LESS and embraced Angular, Ionic, Firebase and Node. I did all the design and UX work. I learned photoshop like tools to create images. I created AWS accounts, spun up instances, created node servers where necessary, used MongoDB for some data storage and Firebase as well. I crunched data from Foursquare, Facebook, Forecast.io and other data sources. I geo located all the golf courses in the country and built other meta data that was golf specific.
What did I learn?
I had forgotten how much I enjoyed the creative and analytical aspects of developing. I have written more than 100,000 lines of code over my career but really have never been hired as a developer. As an entrepreneur I typically focused on certain key areas of product development, data manipulation and analytics. More recently as an investor and advisor, my recent app building experience has been very helpful as I assess the decisions my portfolio companies are making. Here are some of my take aways:
Technology Perspective:
Embrace the excellent emerging tools and services but take a modular approach.
The tools and technologies available today are outstanding for building applications across multiple platforms. Both open source and paid technologies make it faster, easier and more cost efficient than any other time in my career.
This allows for rapid development of complex products. Just always design modularity in and expect changes from the start. Inevitably there will be a need, requirement or desire to change out any one tool or component service in the future.
Hybrid applications have come of age and can be largely coded once and deployed across multiple platforms and deliver an excellent user experience.
Where required, use platform specific components but otherwise use the prevalent web technology stack. This means that folks that build and design web sites can also build applications. Building and maintaining dedicated applications using native software stacks is NOT a prerequisite for building a quality application.
Early stage companies should not choose just one platform to develop for nor should they hire developers for each platform.
The decision to hire staff for each platforms individual software/hardware stack should be based on specific unique user experience requirements for the platform. In most cases this would/should not be required and hybrid development should be embraced.
Use small teams with full-stack developers.
Small teams of full-stack developers are going to be more productive and have a higher degree of success than larger teams of specialists. Less time communicating/integrating and more time building and testing. As a team on one, I was an extreme example and am sure that some initial mistakes could have been avoided and progressed faster if I had accessed more experienced engineers as part of the team but having a team with skills that cross over between front end and back end means better understanding and integrated approaches to solving problems.
In-source the unknown. Outsource the known.
Organizations should only outsource mature and well understood routinized processing of data and analytics. This is particularly true if your core product is the application itself. Keep the core development. I believe that rapid development and iteration is easier, more productive, more successful and ultimately more cost efficient. Outsourcing shifts so much time to requirements gathering for all aspects of the project/application, often where knowing all the design/architectural choices upfront is very difficult.
Building great software is NOT like building a house.
We like to translate the software engineering process using that analogy. We use or apply similar terms: "architecture", "engineering", "plumbing" but that overlooks the greatest feature of software. Iteration. Software iteration is very low cost when compared with building in the physical world. Companies should be designing and thinking about change/iteration from day one. This is a bit more than just embracing "agile" development. Its where and when you invest your time when designing and developing your product. Low cost iteration is one of software's greatest asset.
Keep It Simple.
Easy to say, hard to do. Probably the most difficult and most important design decisions are what NOT to put in the interface and how surfaced or submerged some of the functionality should be.
Investing Perspective
Be wary of early stage investments that are spending too much time and dollars on the initial development.
It should not require that much capital to bring an idea to a MVP (minimum viable product).
Distribution strategy is critical to success.
The friction ( costs, risks, time ) associated with developing an application have never been lower which is part of the reason there are now millions of applications in the app stores. Consequently, it has never been harder to break through. Hard to make advertising itself really cost effective. Particularly for early stage companies.
Conclusions
Building mobile applications has never been easier and the costs have never been lower. That means the entrepreneurs can take an idea to initial product/proof of concept with out requiring much capital. That said, acquiring users and/or customers is not easy. Another very hard problem to tackle efficiently but that is a post for another day.
As for me, I am proud of the app I built. If you are golfer who already maintains a handicap then this app will make definitely make playing with your golf pals a more enjoyable experience and make for more informed friendly competition.
If not the app will probably make less sense but you can "follow" many famous amateur golfers with the app. Just try following Donald Trump by searching for the Donald playing out of NJ. Should Donald take timeout of his campaign schedule to play a round of golf, you will know what he shoots!
Here is the problem:
And now you can download the solution! ( And of course you can always like us on facebook ).
