Keeping track of things

If you‘ve got your UDIDs in place; your spec/designs all agreed; and you’ve at least started to think about your app icons and analytics options; it’s time for the serious work to begin.

Fortunately because this is the App Outsourcing Guide your supplier will be doing most of that for you. However if you want to keep track of all of that work (particularly if there are some aspects coming from an in-house team) then you’ll want to put some simple systems in place. Fortunately there are some fairly easy ways to do this.

Project collaboration software

It is very much down to the project manager (probably you); the type of app being created; and the number of collaborators you have; but you may want to use some kind of project collaboration software for the app project to stay on top of everything. Fortunately there are many online tools that you can have up and running in minutes to help you with this.

I have used many of these products and they can all be very good tools if used well, but the danger can be focusing on the project collaboration system to the detriment of the actual project (OCD types take note). I’ll touch on a few other products too but my main recommendation for most small to medium sized projects is the simple but mighty Google Docs, which has the added bonus of being completely free.

Google Docs

If you’re not already a gmail/Google Mail user then head over to and sign up for a gmail email address (you can use other email addresses but believe me this is easier). Now go to Google Docs ( and get started. You can create documents, spreadsheets, drawings whatever you need.

  • Sitemap (from your original spec)
  • Page by page functionality list (from your original spec)
  • XML / content feeds list
  • Snag list
  • Checklists
  • To share a Google Doc with someone else simply use the ‘Share’ button in the top-right of the document and enter the email address of the person you would like to have access.


    There are a lot of online project collaboration tools, so many you could easily sink a week into trying them all out (believe me I have) but the following are some of the most common products.


    Probably the most well known and well used. Very simple to pick up. You can create projects, upload documents, set milestones and tasks lists and then share access with whoever you want. 30 day free trial, hosted on Basecamp’s servers Basic account $24/month, Plus $49/m., Premium $99/m., Max $149/m, hosted on Basecamp servers.


    Less intuitive (and less marketed!) then Basecamp but also useful for keeping track of large / multiple projects. It is more detailed in places than Basecamp but also less easy to use too and may not suit everyone (and may not be so good if some your collaborators are less technically-minded). 30 day free trial (extendable to 60 days for $10) hosted on activeCollab’s servers One time fee of $249 (Small Biz) or $499 (Corporate), must be hosted on your own servers.

    Action Method

    A relatively new addition, this slick-looking system has clearly had a lot of thought put into it. From Behance, creators of cult book ‘Making Ideas Happen’ and website These guys are obsessed with getting things done. Introductory Plan: Free; Premium Plan $12 a month/$99 a year; corporate packages also available. Hosted on Action Method’s servers.

    Daily catch-ups

    If you have a system that works well for you already then stick with it, however if you’re not sure how to handle things from here, I would strongly suggest a daily catch-up with your supplier/suppliers and, if necessary, any colleagues who may also be involved in the project. Whether you decide to do a conference call with your developer first and then speak to your colleagues, or whether you want everyone on one conference call, is up to you, but where working practices and time differences allow I would have the meeting/meetings every day, at the start of each day.

    A weekly meeting is an invite to turn everything into a ‘moan-fest’ and is also a sure-fire way to suck all momentum out of the project. A quick catch-up with everyone at the start of every day though (if it’s your own team then standing round desks for five minutes will be fine), ensures that momentum is maintained and agreements are remembered by everyone (you can follow-up by emailing what was agreed straight after each one). It also ensures the project is one of the first thing on everybody’s mind at the start of the working day.

    If you can’t manage a catch-up with your developer at the start of each day because of time zone differences, do not despair. Well-managed there can be many benefits to working with a team or teams in different time zones too.

    Using time zone differences to your benefit

    If you can structure the project so that there there is a clear understanding of what work will be carried out in each location every day (and a review and re-assessment of priorities at least once a day to support it) you may find that you suffer no negative consequences – and in fact see some benefits – to being in a different time zone to your supplier. To give you an example, I worked on an app project where I (the client) was in the middle of two development teams (one ahead of my time zone, one behind) but it really worked to the project’s benefit.

    The first team (located several hours in front of me, who I’ll call Team A) was building the code for the app and the last few hours of their day overlapped with ours. Towards the end of their day Team A would send me a new build to test and, because of the overlap of their working day with ours, were still able to have a conference call catch-up with me before they left the office. This overlap of a few hours also meant I had time to do a quick test of the build before the call and then discuss any issues from the test with them during that call. During the rest of the day there was then still time for my team to do a deeper test of the build and email any further points back to Team A (who would then have everything waiting in their inbox for them as soon as they came in the following morning).

    The second team (who I’ll call Team B), were located several hours behind me but still with a few hours overlap. Their role was to guide my team with building the content (XML) feeds for the project that pulled most of the information into the app. (Due to the time constraints on the project we were forced to work on the build of the app and these feeds in tandem). This meant that members of my team could work directly (via Skype etc) with Team B in the afternoon, getting feedback and building / updating the feeds. After my team finished for the day (and stopped altering the feeds), Team B were then able to do a thorough and stable test of them. Any further feedback from Team B after this test was then emailed to my team so it was waiting for them as soon as they came in in the next morning.

    Doing this we were able to effectively leverage one normal eight hour working day into 16+ hours.

    It’s great to put systems like this in place so things can work as efficiently as possible (and without having to be involved in every small decision), but whatever the time difference I would always recommend at least a daily catch-up with everyone involved. You might have good days and bad days but whatever happens you should always aim to maintain momentum (even if it’s just making sure everyone knows the priority stuff to be worked on tomorrow.)

    (If you are also acting as the project manager on your side you may also want to speak one-on-one with the project manager on the supplier’s side several times a day as well. Particularly in the latter stages of the project.)