For the past several months, I’ve been creating a product using freelance developers on Upwork – and it’s been fantastic. Currently, I have branches of my iOS app being built by 3 different mobile developers – including a woman from Hong Kong, a gentleman from Ukraine, and another from Germany. In addition, a developer in Pakistan hops on Skype calls with me to help me evaluate project timelines and committed repo builds.
Why am I working with several developers and not just one? It all started from a place of fear. I was afraid of theft – that some developer in a far off land would steal my product, repackage it, and launch it on their own. Well, those fears haven’t completed dissipated. I’m still very cautious when entering into a new working relationship. Two of these guys have been with me since day 1, and it’s gotten to the point where I trust them implicitly with my code base – and also in terms of cost/invoicing.
But here is how I approach working with a new developer: I give them a blank, private repo on Github, and ask them to commit their work to it. In these cases, the work has not been dependent on the entire code base. Thus, they could work in this silo. For example, in 1 round we just focused on the layout and interactions of 1 screen in the app – no back end was required. In another case, where a backend was required, I mocked up a “faux app”.
Part 2, The “faux app” process
My app requires a login flow that allows the user to “skip to browse”. When they are in browse mode, they can’t create certain actions – and they can’t observe certain user-protected screens. In order to hide the entirety of my project, and simply build a working relationship with a new developer, I created a simple, simple app – I title this the “YesNo App”. And here I emphasized with the developer that this entire iteration was about the user experience of the log in and sign up process – including all the error messaging that accompanies such a process – in particular, errors related to duplicate account creation when a user authenticates using Facebook, and then tries to authenticate once again with that same email address.
There were moments where the developer was incomprehensible about what I was asking them to develop – the app was so ugly, didn’t I want him to him make it prettier? My answer – “absolutely not. Pretty is completely irrelevant for this build. It’s all about the tech that goes into making these flows great. If we can execute the tech properly, then we’ll discuss the visual design.”
In the end, the developer coded this entire build without ever knowing what my final app would look and work like – only how the login & sign up flow would feel like – and the flow of being logged in or logged out of my faux app.
Attached is 1 of the specs I provided my developer. YesNo Prototype – Messaging, Flow, Experience
Lastly, I should mention, he needed to build out an MBaaS for this faux app to work. He did so in Parse, then simply transferred ownership of that Parse app to me when the project was completed.
Thus, this “faux app” process allowed me to protect my product while developing a key part of it: the Sign Up/Log In flow.