Best Practices in Hiring a Developer

Client Protection Through Work for Hire Agreement

Brett MillerIT Staffing, Outsourcing, Web Development

Hiring a web developer can be likened to hiring a contractor to work on your house.

No one in their right mind would Google “contractors”, call the first one that pops up, tell them their address, and say, “I need a new bathroom. Have at it.” Not only are you very unlikely to get what you want, you don’t know prices and you might not even have any protection whatsoever should the contractor do a poor job or not finish the job at all.

That’s an extreme example, but it illustrates the point:

When engaging in a web or mobile development project, it’s important to follow a set protocol that accomplishes three very important things for everyone involved:

  • Gives you the best chance of hiring the right developer for your project.
  • Ensures that both you and the developer are clear on exactly what needs to be accomplished.
  • Provides you an “out” should it become necessary at any point during the development process.

Here are the steps you should take to protect your interests regardless of the type of software project (or how easy it might seem):

Define the detailed project requirements in the work for hire agreement.

The importance of this step cannot be overstated.

Too often, unfortunately clients only realize what they want after they see what they don’t want. Not only is this frustrating for the developer, it’s costly to the client, both in time and money. And the worst part is that it’s completely avoidable.

By taking the time to fully document the requirements and scope of the project before hiring a developer, you’re able to bring specifics into the interview process and get a much better idea of which developer or studio is going to be able to best provide everything you’re looking for.

Of course, there are likely aspects of the project requirements that you don’t know yet, and that’s ok. A qualified developer is going to be able to help you finish up your plan once they’re on board. But without the plan completed as thoroughly as you’re able, no developer will be able to accurately and honestly offer a cost estimate or time frame that’s realistic.

I’ll cover more on how the developer can take your incomplete plan and run with it in a later section.

Interview potential developers.

This is a subject I’ve covered thoroughly in the past, and I’m not going to spend a lot of time on it here.

Suffice to say, you don’t want to blindly choose a developer or development company based on something as arbitrary or inconsequential as where they’re located or the generic fee schedule they’ve posted on their website.

Every web development project is different and every reputable developer will approach it in a different way, so generic information provided for a wide audience really means very little.

Choose your short list of developers based on referrals from satisfied clients and/or a thorough search of their portfolio and published skill sets. Then, use this outline of vital questions to interview those developers that match your requirements best.

If you take this process seriously, you should feel very comfortable with the developer you choose. Now it’s time for a trial run.

The paid analysis and design mockups.

This is a stage that many developers don’t even offer, but I strongly recommend it to all my clients, and in some cases I won’t take on a project without this stage being included.

The purpose of the paid analysis stage is threefold:

  • It allows the developer and client to collaborate on nailing down the full scope and requirements of a minimal viable product as well as the finished project.
  • It results in a design mockup and scope document that any developer can use to complete the project.
  • It offers the client and the developer an opportunity to work together on a short-term basis to confirm that both are comfortable moving forward into a longer-term relationship for the full project.

For the protection of both parties, this stage should be considered a standalone arrangement: not connected to or contingent on any agreement to handle the full project. That way, if you decide you’re not really comfortable with the developer or their work isn’t up to the standards you were hoping for, you have an opportunity to walk away with a deliverable (specifically designs and a detailed specification) that you can hand off to the next developer you bring on.

Once development of the full project begins, halting work and starting with a new developer becomes much more complicated and costly.

During the development process.

When you decide to move forward with development of the full project, it’s vital to work two requirements into the formal agreement or work for hire contract you and your developer both sign:

  • Regularly scheduled status update meetings.
  • Scheduled milestones with specific deliverables.

The scheduled status updates offer you an opportunity to stay abreast of how the project is progressing, and gives you a chance to review an up-to-date version of the software to confirm the functionality and progress is heading in the right direction.

Scheduled milestones are different. These are points in the development process at which a specific portion of the project should be completed and provided as a deliverable. That means your developer should be willing and able to supply you the code and any other elements associated with that deliverable at the point the milestone is due.

Generally, it’s best to tie milestones to payment. For instance, a common method is to split the project into stages and pay the developer a percentage of their total fee as each milestone is successfully reached. This offers the developer an incentive for sticking to the set plan.

At final delivery.

Once the project is completed and delivered, you’ll want to thoroughly check every aspect of its functionality and design to confirm it meets all your established requirements in a software development agreement.

This is not the time to be lenient, forgiving, and willing to settle for “good enough.” This is your project and you’ve doubtless invested a considerable amount of time and money into its creation. Before you accept it and pay the developer’s final installment, take the time to make sure it’s as good as it can possibly be.

In addition, pay special attention to the developer’s warranty period and make sure testing continues throughout that time frame with a view to identifying any and every error or snag you can find. Take full advantage of that warranty so you can avoid having to spend more down the road after the warranty expires.

With so many software development projects ending in failure, it’s important to protect yourself going in so you don’t waste time, money, and effort. A professional developer will not only understand, but should actively support your efforts to do so.