When sought-after developers take on freelance jobs, an important aspect that can affect their performance and motivation are the payment terms negotiated at the start of the engagement.
In this post, we’ll explore three different payment options that you have when working with freelance developers — fixed cost, hourly, and retainer payment.
We’ll break down what each means, and explain why, in many cases, a retainer is the preferred payment method for both freelancer and client.
Looking for top talent fast? See how Arc can help you:
⚡️ Find developers, designers, marketers, and more
⚡️ Freelance or full-time remote + fully vetted
⚡️ Save up to 80% with global hires
Hire top talent with Arc risk-free →
Fixed Cost Payment
Fixed cost is exactly what it sounds like. The price is agreed upon in advance, and the final cost will not change, regardless of hours spent. To arrive at the billable amount, the freelancer will use a product requirements document supplied by the client to estimate the total number of hours needed and multiply that by their hourly rate.
Fixed cost may refer to payment based on completion of the entire software project or payment based on predetermined milestones. Some basic milestones might include:
- A completed single-feature prototype for testing
- A completed full-feature prototype
- A completed MVP
The trouble with using a product requirements document or predetermined milestones to estimate hours is that the estimate is most likely wrong. According to a report by the Standish Group, more than 83 percent of software projects are challenged or impaired, meaning they were not carried out and completed as initially planned. Of that 83 percent, a vast majority can be attributed to time overruns.
Most entrepreneurs have a vision in their head of what they would like their finished software to look like, but struggle to clearly define and articulate that vision until it begins to come to life with prototypes. If your initial requirements and milestones change, estimated hours will go up or down, and someone is going to get the short end of the stick.
If the project is completed below the estimated number of hours, the freelancer is getting away with a higher sum than the client would have liked to pay. If the project goes over time, the freelancer is not getting compensated for their additional work and is likely to turn in a lower quality product as they rush to finish.
Brennan Dunn, the founder of Planscope, reminds us: “Unless the estimate is perfectly accurate and the scope never changes, there is a huge amount of risk for you in fixed bid pricing.” While Brennan was referring to the freelancer, this holds true for both parties.
Experienced engineering managers who have overseen multiple software projects know that building software is generally not a cookie-cutter development process. There is no set formula or amount of time it takes to complete a product. Each user case, feature, and tech stack will be different, have different bugs, require different testing, and have a different iteration process.
This iterative process is known as Agile software development. Agile describes a flexible style of development that embraces change, and frequent delivery of software. Agile is often the preferred method of software development. However, Agile is not compatible with fixed cost payment — when original requirements are reached, your product is finished. Period. The developer is not likely to make changes without additional compensation.
Another reason many project managers are skeptical of fixed-cost payment terms is that the developer assumes a lot of risk. “Great!” you say, “Better him than me.” Wrong! The freelancer’s risk is your money…and your risk, for that matter, of ending up with a product that is inconsistent with your vision. After all, any rational developer will estimate the number of hours up, rather than down, to absorb the risk that the project will run over time.
Think of fixed-rate pricing as a flat-rate car service. You pay a fixed amount of money to get to a destination. On the surface of it, it sounds like a good deal. However, for the driver, time is money. With fixed-rate service, you are more likely to get a reckless driver. The faster the driver gets to your destination, the faster they collect your payment. Therefore, the driver runs traffic lights, drives on the shoulder, and puts your life and the lives of pedestrians at risk.
There will be no bathroom stops and no route changes (except for that shortcut the driver didn’t tell you about). You ask to stop at a burger joint you’ve seen signs for along the way, but the driver says “No, it’s not on our route.” By the time you arrive, you’re hungry, you really need to use the bathroom, the car is banged up, and you realize you would prefer to be in a different destination entirely.
Ok, yes…this is all a little dramatic, and we hope you don’t find yourself in such a dire situation. The point is, in a fixed cost arrangement, any changes will have to be renegotiated, and side-stops may or may not be allowed. If you didn’t give very clear directions in the first place, you’ll be in a real pickle if the driver is unable to make adjustments.
By deciding everything up front, you’ve eliminated many possibilities for flexibility and iteration. Just like the driver, the developer may not be able to accommodate your request for changes. Software development is exponentially more complex than a car journey from point A to B — at the outset, you may not know the best development route, you may want to change the route (pivot), or change the destination (end-product).
Read More: How to Do Taxes When Hiring a Freelancer (Software Developer Clients)
Hourly Rate
Paying by the hour is more agreeable, accurate, and flexible than fixed cost. By paying per hour of development time, you can request changes as needed, and have the option to use Agile development practices. It is not uncommon for time tracking tools to be used to track hours, which makes for transparent invoicing. Both the client and the freelance developer will get fair value: an hour of pay for an hour of development.
While pay by the hour is certainly fair, it may not be the most efficient method for time-sensitive objectives. Hourly contracts do not specify the amount of time to be spent on development, they merely set a rate of pay. Therefore, hourly payment terms are most common for maintenance work, or for keeping a developer on the payroll when work is expected, but volume may be inconsistent and goals are not always defined. For businesses managing multiple freelancers, payroll software can simplify payment processes, ensure accuracy, and reduce the administrative burden for recurring or variable hours.
The developer is not guaranteed work, therefore, he or she is not required to prioritize time for the client’s programming tasks. This is more like an open-ended contract that either party can walk away from after any payment cycle.
Again, let’s think of this in terms of car service and automobiles. If you just need some brake work or maintenance done, an hourly rate makes sense.
However, if you’re taking a road trip and want to hire a driver, think again.
Suppose you hire a driver in New York and say “We want to go to the West Coast!” “Okay sure,” says the driver. You agree to pay the driver on a weekly billing cycle for hours driven. But the driver did not promise to drive a certain number of hours each day, and you did not specify if you wanted to go to LA or Seattle. In this case, you may or may not reach the West Coast before the driver has a better job offer, and you may or may not end up at your ideal destination. This is your standard hourly contract.
Read More: Good Developers Don’t Always Make Good *Freelance* Developers
Retainer
Just like the above two options, retainer contracts are based on an hourly rate but specify the number of hours and weeks the freelance developer is to be retained. This means the project manager can, for example, ensure that the developer will be available for 20 hours per week, for 10 weeks. Whatever agreement is reached between client and developer, the developer guarantees that he will allocate that number of hours per week for that many weeks to the client.
This creates the most ideal situation for value creation through your software development journey. As prototypes are tested, iterations can be made. As user feedback is received, features can be added, removed, or modified. As you learn more about your product and potential customers, you can work with your developer to optimize the final product with a greatly reduced risk of inflexibility or an absent developer.
Should the client wish to exceed the weekly retainer hours, their contract should detail an alternative arrangement for additional hours of work. Work that has not been completed within the weekly retainer hours can be paid at a more favorable rate or can be rolled over to the next week. If it appears that the contract’s timeframe will expire while development is ongoing, it will likely be possible to renew the contract or craft a new one suitable to the current circumstances.
While retainer structures vary, this payment method is commonplace in other industries. Lawyers, consultants of all kinds, and even seasonal professions like snow removal, are all often paid by retainer.
Now, back to your road trip. By now, you have learned that the greatest progress will be made by reserving your driver’s time while allowing for flexibility in terms of possible route and destination changes. So, you contract a driver to take you to LA, driving four hours per day for two weeks. You might stop to ask for directions and to reroute for traffic.
After week one, you get to Colorado and meet some locals that say, “There’s nothing to see in LA, why would you go there?” so you ask the driver to take you to Seattle instead. “Sure, no problem,” he says. The trip took a little longer than two weeks because of the rerouting, so you pay the driver 1.25 times the hourly rate, as previously agreed upon for overtime hours.
This road trip is like software development by retainer payment. Stopping to ask for directions can be considered gathering feedback from beta testing. Rerouting for traffic can be considered extra testing for bugs and refactoring. Colorado locals telling you not to bother with LA can be considered customers telling you they are not interested in this feature or that feature.
Switching to a destination of Seattle is the resulting change in product requirements. The extra fee you pay the driver is the modest trade-off you make to get the most ideal finished product. Just like the driver, the developer will be likely to accommodate your requests, because the terms of your agreement mean he or she will be fairly compensated for it.
Read More: Toptal vs Upwork, Fiverr, Arc: Where to Find Great Freelance Developers?
Trust Your Driver
Any time you let someone else drive you around, there has to be a certain degree of trust. Just like you would check customer reviews for car services or ratings on Uber, you should review the past work of freelance developers before you put them in the driver’s seat. You should review their professional portfolio, GitHub account, and even testimonials, if available.
The best remedy for a trust deficit is to hire for experience and quality. Everyone knows there is no such thing as a free lunch, so be wary of developers with rates below market price. Good freelance developers rely on their reputation to find future work, so it’s in their best interest to be upfront with clients, communicate clearly, and deliver quality work. This is the kind of developer you want on your journey.
Use a Freelance Platform
Similar to the way rideshare platforms like Lyft or Uber help passengers feel more confident in their driver and journey, platforms like Arc help to facilitate trust between developer and client by offering the following:
- A trial period to build rapport and see if the developer is a good fit
- Escrow style payments are released only when work is approved, for the added security of both parties
- Project management guidance to keep the wheels turning
- A dispute mechanism should you get in a fender bender
Read More: Hiring Developers Online: Freelance vs Recruitment Agencies vs In-House
Recap
As we have discussed throughout this post, it is difficult to accurately map out a software project from start to finish. Changes in requirements, unforeseen need for extra testing, and additional iterations are a natural part of software development.
It’s fine to have a budget and deadline in mind at the outset, but the high likelihood of reroutes and pit stops suggests erring on the side of flexibility. While fixed-rate and hourly-based payment terms can result in successful engagements, to maximize efficiency, quality of the end product, and fair compensation for work, a retainer is most likely your best option.
Be flexible, and find the right driver to get you to your software destination.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 450,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
