Click Here to Request a FREE Quote to Develop an iPhone App or Android App

How can I tell?

How can you tell if your developer is doing a good job?

Sounds like a simple question, but the issue is surprisingly complex.

  1. The developer might not develop the app you want.
     
  2. The app might look right, but it might be buggy, with frequent crashes or malfunctions
     
  3. The app might be incomplete – there might be important missing functionality, which only becomes obvious after the app is released
     
  4. The app might work fine at first, but as the app grows in popularity, the app could slow down, until it is unusable.
     
  5. You might want to engage a different developer to add a feature, but the original developer could refuse to provide source code – access for the new developer to make changes to the code
     

 

  1. The developer might not develop the app you want.
    The easiest, in fact the only way to control this is to make sure you agree a design up front, and to demand the developer send you frequent prototypes. A prototype, as the name implies, is an incomplete version of the app, which you can install on your phone or iPad. All mobile devices support prototyping.

    There is no substitute for playing with a real version of the app, even if it is incomplete.

    If after testing the app, you discover you need to change something, refer back to the agreed design. If the developer has deviated from the agreement, they should amend their work at their expense. If your discovery means new functionality has to be added, or changed, then you need to make a new agreement, and agree a new fee, with the developer.
     

  2. The app might look right, but it might be buggy, with frequent crashes or malfunctions
    Bugs and crashes during development are normal. It only becomes a problem if the problems aren’t fixed before the app is released.

    Demand all bugs are investigated and corrected before release. Dedicate time to testing the app. Sometimes bugs occur because the developer misunderstood your requirements, so you have to test everything. Do not make the final payment on the app until everything works.
     

  3. The app might be incomplete – there might be important missing functionality, which only becomes obvious after the app is released
    The basic rule here is, if it is in the design, it should be in the finished app, otherwise it is outside the scope of what you agreed to pay – you need a new agreement to cover the additional effort required to add the extra feature.

    A good developer will help you identify such gaps during the design process, but sometimes gaps slip through the design process. Occasionally a gap in functionality is not identified until you start getting feedback from customers.

    The best ways of managing this issue is to pay attention to the design, to test the app prototypes, test them thoroughly, show prototypes to your friends and ask them to test them, and solicit as much feedback as you can before the app is released to the public.
     

  4. The app might work fine at first, but as the app grows in popularity, the app could slow down, until it is unusable.
    This issue normally only affects apps which have to share data between different users, apps which have a server component. And it is a surprisingly grey area. If you receive an app from a developer, don’t expect it to work without modification for a billion users. Companies like Facebook and Google spend hundreds of millions of dollars every year maintaining vast data centres full of high powered computers, to provide the performance we’ve come to expect. It is unreasonable to expect similar performance for this many users, without a similar investment.

    Generally I recommend clients discuss performance during the design stage. If the app starts slowing down with a few hundred users, then I would normally count that as a bug which has to be fixed by the developer. If the app starts to slow down with a few hundred thousand users, then its time to look at investing some of the profits from the app into building a better, faster server.

    If an app is likely to grow out of its server box, cloud computing solutions like Amazon EC2 can be a good solution for scaling server capacity. EC2 offers rapid scaling of server capacity – you can add or remove servers by pushing a few buttons on a web admin form, and scale server computing power up to enormous levels, to keep app response times snappy. By the time your app outgrows a service like EC2, you should have enough money from the app to buy your own data centre.

    The cost and benefits of using a cloud computing solution for the server should be discussed in detail with your developer, during the design phase of building your app.
     

  5. You might want to engage a different developer to add a feature, but the original developer could refuse to provide source code – access for the new developer to make changes to the code

    This is a very difficult issue in computing. A few developers try to “lock in” clients, by refusing to provide them with the code for the systems they developed. Sometimes there is a legitimate reason for refusing to provide part of the code, for example if the developer has included sensitive intellectual property which might be ripped off and copied if the sourcecode was released. But all too often refusal to supply sourcecode is a dirty trick used by the unscrupulous, to try to force you to always deal with the same developer.

    My policy on sourcecode is very simple. When the project is finished, and the last payment made, the sourcecode is yours. You paid for it. If any intellectual property issues ever arise which might prevent total sharing of code, they should be discussed up front, and agreed in writing, before the project is started.

Leave a Reply

Your email address will not be published. Required fields are marked *