Product engineering partners who provide fixed estimates and those who bill on a time and material basis differ in their approaches when it comes to a few things.
- Pricing In practice, engineering partners who quote a fixed price have to markup their pricing significantly. This is because it is impossible to discover and document every detail of a project at the very outset, and changes are bound to happen as the project progresses. To protect themselves against the risk of having to work for free to build some aspect that was missed, fixed price development partners factor a contingency cost into the pricing. Often, the contingency cost may amount to as much as 10%-50% of the plain vanilla estimate. The engineering partner may also demand a significant advance upfront which typically amounts to 30%-50% of the total price to account for the payment risk (as they would be working out of pocket until the project is completed). In contrast, the time and material model allows for a more equitable split of risks between the engineering partner and the client and this is usually reflected in more beneficial pricing for the client.
- Accommodating changes to the project
- Winding down the engagement As your company’s needs and the project’s outlook change, you may need to either ramp up or scale down the engagement with your remote product engineering partner. The inherent flexibility of the agile development model allows you to scale your team in a perfectly linear fashion without much hassle or financial outlay.
In the real world, it is impossible to define in detail a project’s requirements. As the complexity and timeframe of a project increases, so does the element of ambiguity, which can only be resolved as the project gets underway and more granular information becomes available.
An engineering partner who operates on a fixed price model will prefer to avoid changes to the project, simply because it introduces an additional layer of complexity and demands negotiation over each change. In contrast, an agile engineering partner who operates on a time and material basis will expect changes and will be happy to accommodate them as needed.
If your project is simple, well-understood, and short term in nature...
...such as building a simple website or an MVP of a product, a fixed price model would be more than adequate. Projects of this nature have few components which are often well known and documented in the wider software development community anyway. As a result, there is very little that can go wrong and it is easier for an engineering partner to provide an accurate price estimate upfront.
If your project is complex and has a longer timeframe...
...a time and material model would be a better choice. The reason being that it is simply impractical to try to document a project’s details to the last detail with the aim of providing an extremely accurate fixed price estimate. Even if it was possible to do so, the task would take many, many months and if the project has a very long timeframe and roadmap, it’s scope and features are bound to change over time anyway.
Given this problem, keep in mind that if you choose to partner with a fixed price vendor, you will spend a lot of time arguing over billing as each party tries to figure out which parts of the project come within original scope and which ones don’t. The endless back and forth can quickly become a distraction, and is something you may be better off avoiding altogether in what could potentially be a long term business partnership.
If you’ve reached this point, congratulations, you now have a very good understanding of how the remote software product engineering industry works. With this knowledge alone, you will be able to commence your search for a good remote engineering partner, and avoid many missteps. But how do you zero in on the perfect partner?
We aim to provide answers to that question in the next chapter. Click on the link below to read!