Finding my developer
For me, this was the hardest part of the process. Not least because for some reason iOS developers were the one type of person I seemed to lack any connection through my network to.
I tried a couple of prongs of attack to find one:
- Asking friends and colleagues
- Twitter/LinkedIn shout outs
- Sites like PeoplePerHour, oDesk (now Upwork) and so on
Eventually I decided to use the final option and put out a brief on oDesk. It was important that the brief was vague enough to not put the idea at risk but detailed enough that it got some interest.
I outlined the stage the project was at, what assets I had ready and the type of person I was looking to work with.
Unfortunately there are a whole lot of people on there that mindlessly applied to the job without even reading the description. They are easy to spot with their generic applications and fortunately oDesk has a good system of allowing you to shortlist the people you are interested in.
If you do end up having to go for an unknown freelancer via one of these websites make sure they have good reviews and are not brand new to the website. Another thing to watch out for is people who have done lots of $5 basic jobs to get their ratings up.
Download and try some of the apps they have created. Most importantly have a chat to them on Skype about their experience.
This will be a good point to test how well you can communicate with them too. I have worked with off-shore developers before on various projects in the past and so much can get lost in translation where there is a poor grasp of English.
Briefing the developer
Getting the brief right is again very important when speaking to a developer. You might like to consider getting them to sign a non-disclosure agreement [NDA] before presenting your idea to ensure your intellectual property is protected.
Luckily I found an offshore developer who seemed to know her stuff and even challenged me on some of the UX (always a good sign).
The prototype was even more useful here as it gave the developer a great way of seeing exactly what I was after and an indication of the kinds of interactions and animations they would need to build.
Topics we discussed were around:
- Background to the project
- Format of the brief (would they prefer user stories vs a functional spec vs working from the prototype for example)
- Compatibility (What versions of iOS / devices) would be covered
- Approach to bug fixing/tracking
- Approach to releases
- Working style
- What assets would be required for them to get to work (fonts, icons, designs)
- Estimated Timescales
Your requirements may be different but I put great value on a developer who understands the user centred process and also who has some understanding of UI/interaction design.
This is important because they will need to be able to interpret the prototype and the screens the visual designer has created and turn them into working code.
There may be UI issues that need to be solved, or haven’t been identified until the build begins and a developer who can work with you to solve these rather than just mindlessly following a spec is a great boon.
Setting things up with Apple
This was the one area of building this app I wasn’t too concerned about – after all Apple has great UX generally so I couldn’t see why getting myself ready on the developer centre would be an issue. WRONG.
From needing to verify your company information using something called a D-U-N-S number which I have never heard of in my life, to the hodgepodge of different user accounts and websites of the developer centre and iTunes Connect. The whole process has an extremely steep and painful learning curve and you will find yourself referring to the help centre regularly.
Getting the actual developer account set up and approved took around a week for me so it is important you factor this into your timings. You will need this up and running in order to be able to get beta versions of your app running on your device.
To be honest I still don’t really know how it all fits together. I was heavily reliant on the developer to get things set up, issue the provisioning certificates for the builds and so on. It’s worth checking with the developer that they will do this for you as it frees you up to do other things.
Building the MVP
It was finally time to get some coding done. This was an area in which I learnt a lot. Not only in managing outsourced resource but also various technical issues and considerations that come up when building an app.
Developing the app threw up a few things which I hadn’t considered when initially speccing out the app:
- Dealing with daylight savings time
- Time input and display based on device locale
- Entry and display of non-English characters
- Setting up devices, certificates and UDIDs for beta testing devices
Managing the resource
Because I still have a day job I took the slightly foolish approach of more or less setting a deadline and letting the developer get on with it using the spec in Trello – getting progress updates via Skype as and when necessary.
Four big lessons learnt here:
- Set lean deadlines. As this was my first app i’m prepared to give myself some leeway as estimations should get better over time. However, being overly generous in timings inevitably means your project will get put on the back-burner if the developer has other things going on.
- Make sure that you get the ability to see builds on your device as soon as possible. Vital. Not only does it give a far better indication of progress than a Skype message but you can catch bugs early and make sure the build is not going in the wrong direction.
- Communicate clearly. ‘Afternoon’ is how people in the UK shorten ‘Good afternoon’. The developer interpreted this as me saying ‘it’s now the afternoon – where is my build?’ and got offended. I’ll say no more.
- Record your decisions. When you have had to make an implementation decision on something in the build with the developer make sure to log what you have decided to refer to later. Otherwise these things have a habit of being misinterpreted or forgotten.
There are a number of different options for beta testing the app from Apple’s own TestFlight system to 3rd party options like Crashlytics.
For this project the Developer recommended we use Crashlytics as it offered some benefits over TestFlight – namely being able to test on older versions of iOS. The first step is to get the email addresses and UDID’s of your beta testers.
The UDID is a unique code that identifies a particular device and is needed to allow it to run pre-release software. I found whatsmyudid.com a useful link to send to my testers as it gives them a step by step walkthrough of how to get the code to you.
I passed those details onto the developer, they set up the accounts and we were able to start installing and running test builds on our devices. Whenever a new build was available Crashlytics sends an email with release notes and a link to download the new version to all testers.
Logging any bugs was done via Trello in a bugs column.
Testers were asked to capture:
- Operating system
- A description of the bug
- How to replicate the bug
- A screenshot (where applicable)
- What the desired behaviour should be (where applicable)
The developer then worked through these in the same way as they would the backlog.
Next time: Release and marketing
Meetmate – get a reputation for great meetings