What Everybody Should Know About Contracting Developers
One of the key pieces of my app success has been working with the right developer at the right price (which, by the way, doesn’t always mean cheap).
Working with a developer for the first time can be scary. You might now know how to speak their language, or you’ve never seen code before… that’s okay! The good news is you don’t have to know anything about coding.
After working with almost a dozen or so devs I’ve found it’s not too bad as long as you follow a few important rules.
Know your project goals
You have to start by really understanding your project goals. Do you want to test a new product idea or make something really awesome regardless if people use it?
Depending on your goals your developer needs will fall somewhere in this spectrum:
The more you move to the right, the more you’ll pay, but the more the developer will “think” for you.
Pay them to Code, not Think
One of the key things to understand about finding a contracted developer on the left is that they want specific, exact instructions. They’re not being paid to think for you; they’re merely turning your ideas into code.
And that’s fine! You can still get “good enough” products made to test a market, if that’s your goal.
A smart way to make this work is by creating mockups. Showing them a picture of what you want built willl do more to explain your project than anything else.
My very first Elance project I had no clue what I was doing, but I made the below mockups for the very first version of my app. I didn’t care about what the mockup looked like, I just need to show the contractor where the buttons went and overall layout.
Once your mockup is ready you can post confidently to Elance.
Hiring on Elance
Elance is great for finding “good enough” developers. To find a good fit I look for people who:
- Have good reviews
- Have a decent portfolio
- Speak English well
- Are very responsive
Sometimes I’ll just ask them a question to see how long it takes to respond. Hiring an unresponsive contractor is a terrible experience so you want to get that out of the way as soon as possible.
On smaller scoped projects I also prefer working with individuals versus agencies. That way you know what you’re communicating about the project is going straight to the person doing the actual work.
Skype is your Friend
Once I’ve narrowed my choices down I’ll interview a few people via Skype. I want to get a feel for how we communicate with each other.
“Does she understand me when I describe product features?”
“Does he ask good follow up questions?”
It also helps humanize each other. This is very overlooked with Elancers, myself included. I’ve worked with so many people now that I often forget that on the other side is a breathing, living human being.
Seeing and talking with that person goes a long way towards a great working relationship.
Negotiations & Milestones
When negotiating terms with a new developer remember that the power is generally on your side. You have 10+ people bidding for your work. You can set the terms.
A great term you can use to protect yourself are milestones.
The idea is to put the majority of the contract payment at the end of the project. Personally I like setting 50% of the contract price as conditional upon Apple approving my app. That way if Apple rejects it unexpectedly your contractor hasn’t made off with the money. They’re still bound to help you fix it.
Some might say that’s unfair to the developer. If Apple rejects my app why is that the dev’s fault? The key is that you both set expectations and agreed to those terms upfront. Of course the contractor can turn down the job.
There are also very talented, professional developers on Elance. And there’s even a way to hire them on a budget, too.
It’s turns out it’s really hard for new contractors to win their first Elance job because they don’t have any reviews. You can use this to your advantage.
What this means is sometimes great developers will work for really cheap on their first few jobs just to get into the game. That’s how I found the amazing developer I have now.
He had no reviews, but:
- He had a great portfolio, including his own apps in the App Store
- He spoke amazing English in our Skype interview (he’s from Europe)
- He answered all my questions intellegently, and had smart questions of his own
- And he was willing to work at a discount, so I figured I could take the small risk for a great developer
I pay him much more now (see below) but that was the start of a great working relationship.
Of course hiring is only half the battle. Managing developers is a different story.
While yes, you have hired the contractor and yes, you are paying them, you still have the choice to make their life easy or a living hell. They do their best work for their favorite clients so it’s in your interest to make them happy.
Know what you want
I was once told by my developer that he likes working for me because I know what I want. So again, make mockups! Just doing them on your own makes you think through how the ap will work.
That’s much better than going to a dev and saying “I want a Bible app. Go.” That requires a ton more work on their part.
That said, don’t feel like you have to stick 100% to what you showed them initially. As development progresses you’ll realize some changes need to be made. That’s ok. Just be reasonable about your requests.
And if you don’t know whether something is reasonable, ask your developer.I’ve been surprised on multiple ocassions when the answer is simply “yeah we can add that no problem.”
When you’re reviewing a build and you don’t like something, be as specific as possible as to why.
Ideally you’ll describe: (1) what you don’t like, and (2) what would make it better.
I admit this can be really hard to do. Sometimes it’s just a gut reaction and you don’t know why you don’t like it.
That’s okay if it’s only ocassional and you admit it (e.g. “I don’t like how this works… sorry I don’t know why/can’t give a better reason”) but if you do it too much you’ll frustrate your developer.
Remember: reduce ambiguity. A well-defined and scoped problem with specific feedback is a developer’s best friend.
Pay them Well (if they’re worth it)
This only applies to the best developers.
True story: A few months ago I rehired Bart. He’s a 100% class act. He does great work, gives quick but thorough updates, gives me unsolicited advice on how to make my apps bettter, etc. He takes care of me as a customer.
When we first agreed to this new project we agreed to a price of $4,000. That’s a lot for my little company, so I swallowed hard and went for it.
But as time went on and I thought more about the app’s requirements and the importance of this rebuild I reconsidered.
The guy is amazing and has done great work for me before. Why shouldn’t I show him that I appreciate it?
So I emailed him one day and said “hey, I want to do this right and I want you to know I appreciate your work. I’m raising the contract to $6,000.” He didn’t ask for that, I just did it.
Now, can I directly measure what impact that’s had? Not really.
But personally, I feel better working with him. I feel more comfortable making the occasional additional request. And I know that if he thinks something isn’t right he’ll tell me. He trusts that I’m not trying to screw him over.
Pay them Quickly
You think this would be obvious.
But many a contractor’s fear is not getting paid. Who doesn’t have stories of calling clients about invoices 90+ days outstanding?
So my rule is: — Do I have the cash to pay them? (I hope so or why on earth did I hire them) AND — Am I satisfied with the finished project?
If both of those are true then I cut the check.
“But you should wait for the invoice….didn’t you get Net 30 terms?”
That’s exactly why I should pay quickly. It will surprise them and they’ll want to work for me again. They’ll try and keep me as a client by doing great work.
I once paid a developer literally 5 minutes after he sent me the invoice. He was going on a trip soon and I knew he’d want to get his loose ends tied up as soon as possible.
After I sent the payment he quickly emailed me, saying that was the fastest he’d ever been paid!
Remember: developers talk to each other! Not only should you treat them well because that’s the right thing to do, but because your reputation is important.
Depending on your project goals you can find a good developer at a reasonable price. And if you treat them well that relationship can grow into something powerful.
Talk to me more on Twitter.
If you liked this essay....
Then consider signing up for my newsletter, How It Actually Works.
It contains the best material I find anywhere – this means books, articles, podcasts, research, videos, Twitter threads... the most interesting stuff that will give you something to say.
1,000s of people read it every week and they're never published anywhere else. Once they're sent they're gone forever.