How do you hire an offshore developer or agency for a medium-sized project? I do a lot of these for clients, so today I’m going to share my playbook.
First, why did I set those price boundaries? Larger projects look more like full-time hires, and shorter projects are more likely fixed-bid. Let me know if you’d be interested in separate articles describing $2k projects and $2M projects, which are quite different.
To start, you may as well prepare the text you’ll copy-and-paste for your workflow. The job description and the first few interactions with candidates can all be scripted.
You don’t have to do it all at once, but I recommend staying at least one step ahead. Here are the items you’ll need to write. I’m assuming you’re going to post this listing on Upwork, but other platforms are similar.
JOB DESCRIPTION
Gig Headline
“Native Mobile App Dev Needed for Health Care” or “AdTech B2B SaaS App needs Python Data Science expert”.
The headline will appear on the CV of the person who gets this gig, so your goals are to:
- identify the platform so they know at a glance if they’re right for the gig
- specify the sector to adds credibility so your listing doesn’t feel spammy
- use a complimentary tone so the contractor will be proud to have this as a successfully completed gig in their portfolio someday.
Gig Body
Give some more detail about the project. What programming language(s) will be used? Who will provide these facets of the project, from high-level to low-level:
- UX (logical sequence of interface flow, tone, assumptions about the user)
- UI (graphic design and placement of specific controls)
- FRONT-END (user-facing code, such as HTML, CSS, Javascript, or on native apps the “view” components)
- BACK-END (code for fetching and storing in database and file folders)
- DEV OPS (the logistics of server setup, deployment, storage, load balancing, logging, backups, etc.)
- QA (quality assurance by someone who is not the person writing the code)
Will you provide some of those, or is the dev shop providing all? Bear in mind that no one individual can be great “up and down the stack”.
Pro tip: I highly recommend using a separate QA shop that isn’t the developer; nobody should check their own work. Plus QA tends to be cheaper than dev, so you can save money by splitting this off.
Try to describe what broad capabilities the product will need to have — does it include building user profile, social connections, location-based sensing, filtering large database, audio/video, heavy graphics, or special math? Be clear about which tasks/skills are part of the job, and which items will be provided for them.
Do you already have a design? Is it a napkin sketch or a fully-functional flow in Figma? If it’s a full flow, does it also include simulation of every button and dialog box, every field that can have a show/hide option? You’re not going to send your actual design in the job listing, but you should tell the candidates whether you have one.
What APIs do you expect to require? This means, what kinds of other companies will be part of your offering? Will you need a Payment Processor? Google Maps API? Email Service Provider? You don’t necessarily need to list all the connections you plan to use, but it’s helpful to say what kinds of connections.
The gig body can be several long paragraphs, or 150-250 words. Let them really understand the project.
Gig Cover Letter Questions
You’ll have an opportunity to write custom questions into your listing. I recommend writing one or two, maybe asking about qualifications or portfolio links to projects similar to yours. This is an opportunity to see whether they have any close matches or not. Also to see whether they read your requirements at all.
Lately some shops have started using AI to craft their responses. If the responses parrot back your job description but seem to lack substance, don’t be too impressed.
MANAGING THE HIRING DECISION
Write Your Invitation to Apply
Plan to invite a dozen candidates who look reasonable. Write a very short invitation for them to check out your gig. 1-3 sentences is enough; it can just say “Hey, I’m hiring for a dev job in Flutter [insert platform], and thought your profile looked like a good match. If you’re available for a new project, take a look at my listing?”. Don’t say much at all, because it’s spelled out in your Gig description.
Be Ready to Answer With Real Project Details
When you decide you’re interested in a candidate, it’s already time to send more details about the project. Have this ready to cut-and-paste, whether it’s links to downloadable items, a ZIP, a PDF, or anything else. You’re going to show them your lists of requirements, your interface sketch (whether it’s good or bad, vague or detailed), and ask them for a rough bid. They will say that they can’t commit to a flat rate, and that’s fine. But this will be the time to start putting numbers on it.
Shop for Some Candidates
You can pro-actively browse people who the platform considers to be a good match. This is also a valuable stage because it will get your first dialog rolling right away. If people misunderstand your job description it’s not to late to ake changes. If bids seem wildly different from your expectation, you can figure out why.
For filter criteria, I aim for 90%+ satisfaction on prior jobs, English as “fluent” (the standards are low, so I wouldn’t go lower than “fluent”), and I don’t want brand-new accounts (too much risk they had a previous account and shut it down from bad ratings). You want to see a large number of jobs completed, especially at a size similar to the gig you’re offering. If you’re hiring a $40k project and someone has 100 jobs in the $500-$2000 range, they may not have the right skill set to manage a project of your complexity.
To assess developer skill sets,
you may want a CTO
with their own experience.
You want applicants whose skills closely match your project. Not a list of a hundred skills, just a tight focus on your specific needs. Sometimes this is about choosing between equivalent systems, such as React vs. Angular. They’re both toolkits that enhance Javascript for making web pages that work more like local apps. But they’re complicated, and someone who knows the ins-and-outs of one system might be stumbling their way through the other.
For a full-time hire I wouldn’t prioritize this (because people can learn), but for a short-term gig you want them already up-to-speed. Also look at whether the “developer” has a profile calling main attention to point-and-click systems such as Wix and WordPress. Even though those systems can technically be extended, and some of those extension authors are very talented, the majority of “devs” listing point-and-click platforms on their profiles can only handle the most basic cut-and-paste coding.
Ask for Proposal With Budget and Timeline
A well-written gig will get a dozen applicants within a few hours, and maybe a hundred over the next few days. Don’t stall them. Send the package you prepared with all your sketches, diagrams, list of requirements, or anything you have.
Try to get them to offer a number, or at least a high-low range, before your first meeting. Hopefully the bids will cluster somewhere, with maybe a few outliers. That doesn’t mean the lowballer is a bargain, or the one with the high bid needs to be ruled out… but it’s a conversation point. I recommend making a bid a pre-req before you agree to schedule meetings.
If I have 30-100 applications, I might invite 12 to bid, and then offer meetings to 4-6. Avoid launching without interviewing at least 3 candidates.
What To Ask During the First Meeting
Judge everything. Are they articulate? On time? Do their computers work? Can you understand them when they speak? Do they listen to you, or do they make you sit through a big slide deck about how great they are? Ask if you’re speaking with the people who will actually be running the project.
Ask them how they manage their workflow and communications, and what platforms they use. If different categories of workers will be involved (i.e. Project Manager, Designers, Coders, Testers), ask about their relative hourly rates.
Ask whether you’re getting dedicated workers or if their time will be divided across other projects concurrent with yours. Above all, be mindful of how you feel. If you feel uneasy from this first meeting, it’s unlikely to improve.
MAKING THE CONTRACT
Planning First Milestone and Full Project
After you have all the bids, and you’ve met with your top 3-6 candidates, you will at some point need to jump into the pool.
Find a way to section off a 10% part of your project as a trial. You are going to pay for this, and it’s your first gamble because it might not work out. Limit your risk by committing to only a small piece of the project as initial work.
If you get a bad feeling from the start, seriously consider telling them you’re “not ready yet” to proceed, and go back to one of the competitors to try this again. You can even tell the other shops when they’re “shortlisted” that you did a trial with someone else and you were not impressed with the results, so now you’re giving them the opportunity to try the same starting project. Remember, even if you pay for two different dev shops to “do the first 10%”, it’s much better to waste 10% of a project budget than to have the whole thing go bad.
To craft meaningful milestones,
you may want a CTO who knows the
technical challenges to your project.
- THE FIRST 10%: The end result of this proof-of-concept must be something usable. A website where you can log in. A mobile app you can put onto your phone that has more than just a splash screen. Something.
- THE OTHER 90%: If the trial goes well, establish a series of additional small steps for the rest of the project.
Milestones will ideally have deliverables on a timeline like 2-8 weeks. Definitely check progress weekly at minimum, even if the team establishes 2-week sprints.
Checking progress means that you personally inspect the product, not that you take their word for it about which tasks have been completed. By this time you will have a much stronger sense of whether the dev shop keeps their promises, communicates clearly, makes themselves accessible, and all the other aspects of professionalism that will define the relationship.
As each deliverable arrives, test it thoroughly. Many dev shops will allow you to verify individual features or tasks mid-sprint, and this is preferable. Consider employing third-party QA testers; they’re usually inexpensive and objective.
Everyone fears dev projects going over budget, and everyone blames the developers. It’s true that developers can be terrible about timelines. But overages are also often caused by feature-creep on the part of the client. If you want to hold a team accountable, be well-disciplined about saving your wishlist requests for future versions.
GOOD LUCK!
Was this useful? If I were to write another article like this, what would you be most interested to read?
