Suppose you are a non-technical entrepreneur and you have a brilliant idea for a killer app. How do you now go about getting the app developed and what are some of the pitfalls you should look out for? Conversely, what if you’re one of the developers that gets asked to developed it? Over the years, I have seen the same story being played out over and over again, but just with different characters. Here is how the typical story goes:
- The app idea: The story begins with the non-technical entrepreneur. Let’s call this character Marry. She has a brilliant idea for a killer app, but she’s not a software developer herself. She is however very business savvy. Marry therefore thinks that all she needs is to find one or more developers to turn her dreams into a reality. She figures that once the app gets developed and they go-live with it, she can tell the developers to step aside and she’ll take it from there.
- Requirements: Marry puts together a list of basic requirements together. Like most entrepreneurs Marry is very optimistic and sees the app as being very easy to develop. She reckons that it shouldn’t cost too much and the whole process cannot take longer than a few weeks.
- Corporate quote: she approaches a professional software development company to get a quote. Upon receiving the quote she gets the shock of her life. She thinks to herself that she can get a copy of a popular out-of-the-box software product at her local store for a fraction of that price. Marry then gets comparative quotes from other software companies which come in with similar estimates. Since she can’t understand how these companies come to these conclusions about the cost estimates, she figures that all established companies and corporates are being greedy and are all trying to rip her off.
- The software geek: one day she meets a software developer called John. He seems like a nice, honest, down to earth guy and above all very intelligent guy. John is a typical geek that is obsessed with coding and technology. Instead of a wearing a suit, his attire on most days includes jeans and t-shirt. Being young and full of energy John has aspirations of starting his own software company one day. Marry immediately gets a light bulb moment and asks John to get her the app developed. She then proceeds to have a casual chat with John about her requirements. John hasn’t had that much experience in building commercial software products nor does he have any experience in project and cost management. However, he sees Marry’s proposal as a huge opportunity to learn a few new technologies and make some extra cash.
- The agreement: since John hasn’t got that much experience he reckons it shouldn’t take longer than a few weeks. He puts together a basic cost estimate making sure that it’s an offer Marry can’t refuse. Since Marry has a bit of life experience she negotiates with John to bring down the quote. She also asks that they agree for payment to only be made upon completion of the project. Although John is a little reluctant to do so, he agrees, since he reckons that it’s better than nothing. The quote ends up being a fraction of what the professional software company originally estimated. Marry is overcome with joy in finally getting someone to develop her app and knowing that all her dreams will come true in a matter of weeks. Likewise, John is over the moon with getting Marry as his first customer and the opportunity of starting his own software company. This has always been his dream. Just like that two naive but well intentioned and optimistic people enter into a business agreement.
- Bringing more developers on board: although John is excited about the project, he does feel a little nervous about doing it all by himself. Perhaps it could be due to a lack of confidence from a lack of experience, or perhaps he thinks they will get it done quicker as part of a team. He therefore decides to bring one or more of his developer friends into the project and agrees to split the money with them.
- Project inception: since John doesn’t have that much experience, he doesn’t bother with an analysis workshop to flesh out the exact requirements for the app. Being filled with excitement, he and his friends pull out their laptops and get to work on coding the app based on their current understanding of the requirements. John gives Marry a status update every few days about how things are going. Marry is content with the feedback, everything sounds like it’s going according to plan.
- Scope creep: after a few weeks, John announces that the app is finished and ready for go-live. It’s finally time to demo the app to Marry, who at this stage is overwhelmed with excitement she can barely contain herself. They setup a time and date to meet. It’s camera, lights, action! With each second that passes Marry’s excitement begins to fade and disappointment starts to creep in. In John’s defence the app does indeed meet the vague requirements that Marry set out i.e. it has all the buttons, data grids, links etc. Marry begins noting an extensive list of changes that will be required. For example, the UX and styling of the app is all wrong i.e. the colours, images and positioning of the controls. Furthermore, the business logic of the app is not completely correct and in some cases even missing. Although the app is not ready for go-live, being the optimist that Marry is, she says that it’s a good start, but the app will however require a number of “small” changes. Unfortunately for John, Marry doesn’t quite know the exact changes that will be required. For example, she knows that she doesn’t quite like what she sees in the UI but since she’s not a UX designer or graphic designer she can’t quite pin-point what or how it needs to change. She therefore makes more vague requests to John asking him to make the colours lighter and rearrange them a bit to make it “slicker” and more “modern” looking. What defines “slicker” and more “modern” looking to either of them. After seeing the app, Marry also realises that there are a number of business logic requirements that she hasn’t thought of previously. She now mentions those requirements that she can think of off the top of her head. Marry thinks to herself that whatever she can’t think of now, she’ll bring it up later.
- Going pear-shaped: John realises that this will be more work than he bargained for. To appease the customer he decides to let this one slide by agreeing to complete the list of changes. After completing the changes they go through another demo. Since Marry did not have a complete and clear list of requirements, she once again asks for more changes. By this stage John is starting to become visibly irritated because he realises that the workload keeps increasing but the amount of money they agreed on is fixed. Going forward him and his friends will essentially be working for free. He explains to Marry that if she wants changes going forward she will need to pay more money. The way Marry sees it is that that they already agreed on a price and shook on it. Naturally she feels that she is being extorted for more money i.e. she cannot use the app in its current form while John is requesting for more money to complete it even though they agreed on a fixed price. On the other hand John also feels that he is being extorted for his time i.e. he agreed on a fixed price, but since the app requirements keep changing, him and his team will need to work for free with the possibility that they might never finish the project and thus never get paid for their work.
- Jumping ship: after a few cycles of this chaotic coding and demo process, one or more of John’s friends decide to cut their losses and quit, leaving John to fend for himself. For John it’s not that easy to quit, either due to a moral or contractual obligation to complete the project. He is now stuck between a rock and a hard place.
- Recruiting other developers: John explains to Marry that his team members have thrown in the towel and have gone on to greener pastures. He also explains to her that the progress will obviously slow down as a result of reduced man power. By this stage Marry sees his team as unprofessionals and lacking integrity to keep their end of the agreement. She also realises that recruiting more developers to replace John’s team member will require more money since the new developers will obviously not work for free. This isn’t what she bargained for, since she expected a fixed cost for the entire project. Furthermore, Marry believes that it was John’s decision to hire those developers and he should be accountable for that. However, she also realises that she cannot fire John since he is the only one left with the technical knowledge of the design decisions that have been made in the code. Depending on how forgiving Marry is, she may very well forgive John for what she perceives to have been mistakes on his part. Either way, just like John, Marry is now also stuck between a rock and a hard place. Left with no choice, she agrees to start looking for other developers to replace John’s team members. In the long run, throughout various stages of trial and error, Marry will end up paying the full price of getting the app developed i.e. the price that the professional software companies initially quoted her. Alternatively, Marry may also give up on the project if she lacks the funding.
- Future projects: assuming that Marry ultimately gets her app developed, what are the chances of her getting John to develop another app for her in the future? I will leave you to ponder and decide that for yourself.
Now that we have a backdrop for this very common scenario, let’s a do a post-mortem of what actually went wrong and why it went wrong. In terms of placing blame I believe that neither John nor Marry are solely to blame, but are in fact both equally to blame.
- What Marry the entrepreneur did wrong: although Marry may know a thing or two about business, she has limited knowledge and experience on what it actually takes to develop software. Ignorance unfortunately is at the heart of this these sad stories. Here’s what Marry didn’t realise until it was too late.
- Paying for time and expertise vs paying for a finished product: when getting custom software developed you’re not actually paying for the finished product, but rather the time and expertise of the people that will be developing the product i.e. you’re buying development hours. This is comparable to purchasing a finished car out of a shop vs getting a custom car designed, engineered and manufactured to start your own car brand. You won’t need millions but billions to create your own car brand. The same applies to starting a business with software at the core of its operations.
- Pricing of a product: even when purchasing a finished product, the price of it is not dictated by the value of the product but rather by the demand versus supply for the product. In the grand scheme of things and from a financial perspective, if you invest $100K into the development of an app, its value in terms of the number of features doesn’t really matter that much. What matters is the return on your investment i.e. how much money the app will help you make and/or save in the long run. This determined based on supply and demand of the app.
- Finite mindset: Marry believed that software development is a finite process i.e. that it has a beginning and an end. She thought that she could pay a fixed amount of money for a fixed amount of development work to get the app that she wanted. Unfortunately that is not the case. For starters, the main reason being that requirements constantly change just like the world is constantly changing. There will always be new features and improvements that will be required. Older software frameworks and programming languages that are consistently being discontinued need to be replaced by new ones. Security mechanisms need to be constantly upgraded. Not to mention the hardware capacity that needs to be increased in order to scale that application. Let’s look at Facebook as an example: according to them they have 1 engineer per 1 million users. That equates to thousands of engineers working for Facebook all working night and day just to keep a website and mobile app running 24/7. To quote Mark Zuckerberg’s character from the movie The Social Network, “software is like fashion, it’s never finished”.
- Greed and short-sightedness: had Marry realised that the work required on a software product is never finished, she would have realised that there are only two options for getting her app developed:
- Deep pockets: Hiring a contractor might have worked in the short term to get MVP (Minimum Viable Product) created. Long term however, the engineers really need to be working for your company in order to have full control of the product on which your entire company would rely on. Either way, Marry would need to have large amounts of money to fund the ongoing development. She either didn’t have the money or was too stingy to spend it.
- Equity: even if Marry didn’t have the money to fund the development she should still have realised that software development is an ongoing process requiring an endless supply of money and work to keep it going. In which case, she should have offered John equity in the business thereby incentivising him to work for free/less money with the possibility of profiting from the business in the long term,
- What John the software developer did wrong: John isn’t without fault either. He might be a talented software developer, but he had minimal experience in project management, requirements analysis and customer management in general. He pretty much broke most of the rules in professionalism in the software industry. All of these topics are discussed in upcoming chapters:
Binary Chef 