Leigh and I put a call out on Ghacklabs to try to find out where exactly we were going wrong with our tech. This is what happened.
Ghacklabs is run by blogger and startup founder, Luke Fitzpatrick (who is also a university lecturer). It attracts tech and startup founder talent and is our go-to place for knowledge on tech. We got so many responses and some were only two liners so we thought we would set out the longer responses.
Andrei Anisimov (Founder of TechStarted)
- Somebody on your side with strong technical skills – a technical mentor.
From my experience, going into a dev project with zero technical knowledge and nobody to advise you is akin to playing a lottery. The person doesn’t have to be a full-time member of your team, a couple hours a week should suffice to select the right technology stack, review the code, potentially interview candidates.
- If you hire consultants or go offshore – do your homework before hiring.
Many founders are eager to dive right into the development. However, the development is actually the last stage in the Idea -> Strategy -> UX -> Design -> Development pipeline. In my view, bundling all these into a single service to be executed by a single provider is a bad idea and is an example of “management by abdication”. Instead, you want to own each step of the pipeline and work with corresponding professionals to complete each step. Move to development only when you actually know what to build.
- It is important to break your application into smaller milestones/modules/iterations of up to 1 month long.
Treat each as a separate project in terms of deliverables, payments, and testing. This allows to reduce risks significantly and discover problems early. Require daily code commits and at least weekly staging server/TestFlight updates to review the progress.
- Fire fast if things don’t work out.
Unlike SEO or marketing, where results can take several months, if software projects don’t go well within the first month it is unlikely that it will magically improve later. This is another reason why it is important to break the project into milestones and have the first deliverable within 1 month from start.
Paul Towers (Founder & CEO Task Pigeon)
Here’s what I learned through the process.
There are three critical things that I recommend all non-technical founders do when looking to hire and manage developers.
- You have to admit that this is outside your area of expertise. You don’t know who the best person for the job is, or what the best technologies/coding languages are to use. In my instance, I reached out to my network in the Sydney startup scene and was put in touch with a Senior Developer from a coding academy. He helped guide me on what to look for, and even reviewed the proposals/resumes of developers I was speaking to.
- Practice trumps theory. I’ve met some Computer Science grads who are expert coders, and others who aren’t. Regardless of the person’s background or academic success getting them to start with small test project (if outsourcing) is best. If it’s an internal hire then there are a number of online applications that allow you to put together coding tests. This will give you some valuable insight into just how good they are at what they say they can do.
Leigh and I also asked Sydney Startup Facebook group- how do they currently manage internal and outsourced development project and teams.
There were over 20 comments from developers to corporate to agencies to freelancers (including Matthew Ho from Atlassian ( the group admin). Many of the comments included same or similar methods so we would like to take this opportunity to thank everyone in the group who commented, we decided to condense it down best as we can.
Some people use lawyers some people use the Internet (because frankly lawyers are expensive and unless you have pre-seed funding you’ll be a broke startup) so have something more than a scope document in place.
Note that agencies and developers play on the fact that if anything goes wrong you won’t have any money to sue them but at least have something in place to make yourself feel in control and accountable.
We can’t recommend a contract but if you are a start up try Law Path they are backed by Norton Rose Australia (global firm). I personally can vouch for Law Path (and disclaimer I used to work at Norton Rose for 8 years).
If you can afford lawyers, try to avoid lawyers who are similar to the hit it and quit people. They will suck your money dry and give you advice like “you’ll need a non-disclosure statement” when you have no market built, no platform, nothing to show but an idea you had yesterday. Lawyers charge every 6 minutes so make sure before you get to them research exactly what you need from them.
We can’t direct you to a service agreement because we aren’t lawyers. But, read this article from Law Path around service level agreements and contracts.
Here are some further contract tips from the group:
- Include in Service level agreement a phrase around timing/delivery clauses, x days late = y% percentage off final rate. If you haven’t included in your service level agreement a clause around failing to deliver on time…implement moving forward.
- If a developer or agency accepts a fixed cost contract without a detailed spec and penalties for revisions, and it doesn’t sound to be ridiculously overpriced – they no idea what they are doing.
- You learn a lot and adapt as you go and as such it’s difficult to maintain a fixed scope.
- If you are locked into a fixed agreement you have to do variation agreements, which you get screwed on because there is still going to be more changes later. Development never ends.
- Agreements guard you against crappy developers and those you need to be willing to fire them. To be able to fire them you have to make sure any money you have spent is not wasted.
- Include a provision for GitHub or Bitbucket to insist on daily or regular commits and also testing.
- A must is a provision for extensive documentation in the code and for deployment including dependencies and modules needed, outsource versions.
- A good idea is to look at your requirements and ensure that you have not contributed to the problem with some unintended scope creep.
- Imposing penalties after a job has started is unlikely to work. Many will just stop work and disappear if they think they are going to lose money.
- Provision for verbose code commenting AND wiki documentation – this prevents your code base from becoming legacy. Developers take more accountability. New developers can continue rather than start again, and more importantly, you can see that work is being done so if the project is going past due.
- Provision for descriptive commits – not just ‘bug fix’ or ‘copy update’, but something like ‘Added Cancel button to update form: returns user to list view’
- Provision to facilitate a daily stand up through Slack or Skype to ascertain completed, pending and roadblocks
- Provision to provide articulate specifications – try to avoid using the word, ‘simple’
- Provision for unit testing and UA testing plan in the development project
- Provision for revisions, deployment, documentation or contingencies.
- Provision for structured payment schedules, incentive payments for on time and quality standards.
- 60% upfront and two milestone payments of 20%.
At least if you have all this and they don’t perform you can ditch them. If a developer or agency stops taking your call there isn’t much you can do. Simply cut and move on but let your friends in startups know to avoid using these types of people, stick with people playing the long game. Read this on how to manage your emotions!
Even if you have an existing relationship with an agency or developer having these in place is good business.
If the trust is there then you can skip steps to speed up the process but always have a daily and weekly stand up meeting and make sure your project is on track.
READ our next article on how to lower the Bullshit – Developer BS Detector – Basic Tech Checklist