Why AI engineers are hard to hire, and what helps
When an AI engineering search runs five months, the instinct is to fix the process. Usually the problem is the profile, and it calls for a different approach.
Read More
Time and materials vs. fixed price is the choice between buying an engineer's hours and buying a defined scope for a set amount. The third option, an outcome-based engagement, buys the same people at a lower fee up front and ties the rest of the payment to numbers both sides agree on before the work starts. All three answer one question in different ways: when the work turns out harder than anyone expected, who pays for the difference?
That question matters more than the rate on the proposal. Most engineering budgets get compared on price per hour or price per project, and both numbers hide where the risk sits. A team that picks the wrong model for the work ends up renegotiating scope every month, paying for hours that produce little, or measuring results nobody can agree on. This guide compares the three models as they apply to engineering work: what each one buys, who carries the risk, when each fits, and what an agreement tied to results has to settle before anyone signs. The short version: the right model depends less on price than on how well you can define the work.
Time and materials buys effort. Fixed price buys a defined deliverable. An outcome-based engagement buys effort at a reduced fee, plus a share of the payment that depends on agreed numbers. The difference is not the price of the work but what the buyer is holding in hand when the invoice arrives.
Time and materials. You pay for the hours worked at an agreed rate. The scope can change every week, and nobody has to renegotiate a contract to change direction. A time and materials contract is the natural fit for engineers who join your team and take direction from your leads: you decide what gets built, and you pay for the time it takes.
Fixed price. You pay a set amount for a defined scope. The provider commits to delivering that scope, so the provider has to estimate it, and any estimate carries a margin for what could go wrong. Changes to the scope become change requests, each with its own price.
Outcome-based engagement. DevLatam publishes this third model on its home page in one sentence: “You pay less up front. The rest is tied to the numbers we agreed, measured at the end of the period — so we carry part of the risk with you.” The people doing the work are the same; what changes is how the fee is split between effort and results.
In time and materials, the buyer carries the risk of the work taking longer. In fixed price, the provider carries the risk of a bad estimate and prices it in. In an outcome-based engagement, the risk is split: part of the fee is guaranteed, and part depends on whether the agreed numbers are reached.
The split looks different in practice:
None of these is the cheap option by default. Each one moves risk from one side of the table to the other, and risk that moves gets priced somewhere.
The fit depends on how well the work can be defined before it starts. Work that keeps changing fits time and materials. Work that can be specified completely fits fixed price. Work with a measurable result that both sides can influence fits an outcome-based engagement.
Time and materials fits when the scope is uncertain, when your team wants to direct the work day by day, or when an engineer is joining an existing team to work inside its roadmap. It stops fitting when nobody on your side has time to direct the work: hours without direction are the most expensive hours there are.
Fixed price fits small, well-specified pieces of work with a clear definition of done: a migration with known boundaries, an integration with a documented API. It stops fitting when the requirements are still moving. A fixed price on an unstable scope produces either a padded estimate or a stream of change requests.
An outcome-based engagement fits when there is a number that reflects the value of the work, that can be measured honestly at the end of a period, and that the team doing the work can actually move. It stops fitting when the result depends mostly on things outside the team's control, or when the only available metrics measure activity rather than results. If you'd like to compare the cost of the first and third options in more depth, the companion piece on paying for hours or paying for results walks through the hidden costs of hourly work and how results can be measured without gaming them.
Any agreement that ties part of a fee to results has to answer four questions before it is signed: which number is measured, who measures it, over what period, and what happens if the number isn't reached. If any of the four is vague, the outcome-based part of the fee becomes a dispute at the end of the period instead of an incentive during it.
Which number. The metric has to reflect value, not activity. Hours logged, tickets closed and lines of code are easy to count and easy to inflate. Delivery metrics are a better starting point: the DORA software delivery metrics cover throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate). They are a reasonable starting point for teams that track developer productivity metrics.
Who measures it. The number has to come from a source both sides can see, such as your repository, your deployment pipeline or your incident log. A metric that only one side can produce will be questioned by the other.
Over what period. The period has to be long enough for the work to show up in the number, and short enough that both sides still remember what was agreed. The right length depends on the work.
What happens if the number isn't reached. This is the part that makes the model real. The agreement has to say what the provider gives up, and whether anything outside the team's control, like a frozen release or a changed priority, adjusts the target.
DevLatam's site does not publish a share of the fee, a set of metrics or a period length for this model; those terms are agreed engagement by engagement. What the site does say is that the engineers and the employment model are the same in all three ways of working. That is the boundary worth keeping in mind with any outcome-based offer: tying part of the fee to results changes how you pay for people. It does not turn the work into a project someone else owns.
Choosing a model is not a permanent decision. DevLatam describes its three ways of working as “three different situations we keep meeting,” and adds that “you can start in one and move to another.” Because the engineers and the employment model stay the same, moving between models changes the commercial terms, not the people on your team.
A common path starts with staff augmentation: a named role, paid for the time worked, directed by your team. Once the work becomes stable and measurable, part of the fee can move to results. A team whose work repeats and accumulates can move toward an AI-augmented team, designed to need fewer people as the context it builds turns into reusable assets. And if the work stops compounding, the path runs the other way, back to paying for the hours of the people who stay.
Price per hour and price per project are the numbers that get compared, but the decision that matters is where the risk sits and whether the work can be defined well enough to carry it. Time and materials keeps control and risk with you. Fixed price buys certainty with a buffer. An outcome-based engagement shares the risk around a number, and works only if that number is measurable, visible to both sides and within the team's reach.
The practical next step is to look at the role or the work you need covered and ask which of those three conditions it meets today. The three ways to fill the role lay out the options side by side, and if part of your fee could be tied to results, the place to start is a conversation: talk to us about the position and the number that would show it's working.
Frequently asked questions
How does time and materials pricing work?
Time and materials pricing bills the hours actually worked at an agreed rate, plus any approved costs such as software licenses or travel. The provider invoices on a regular cycle, often monthly, with a record of the hours. Many buyers add a monthly budget or a not-to-exceed amount so spending stays visible while the scope keeps changing.
What is the difference between fixed capacity and time and materials?
Fixed capacity reserves a set team for a period at a set fee, while time and materials bills the hours actually worked. With fixed capacity you know the cost in advance and decide how to use the team's time; with time and materials the cost follows the work, so a quiet month costs less and a busy one costs more.
What is an example of a time and materials contract?
One example is an engineer who joins your team through staff augmentation and is paid for the time worked. Your leads set the priorities, the scope can change from one sprint to the next, and the invoice reflects the time spent rather than a deliverable agreed by both sides in advance.
Learn more about nearshore software development by reading the articles from our blog!
