When contracting a supplier for software development, there have traditionally been two dominant models: fixed price and time and materials. Both are well understood, widely used, and deeply embedded in procurement processes. However, both also come with structural limitations, particularly when applied to modern Agile delivery.
Having worked on both sides, as both a supplier and a customer, it is clear to me that neither model fully aligns with the realities of iterative development, evolving requirements, and the need for continuous learning. These tensions are not new, but they are becoming more pronounced.
The rise of artificial intelligence is accelerating this shift. It is changing how quickly software can be built, how teams are structured, and how value is created. As a result, the way we contract for software development must evolve to reflect not just Agile principles, but also the increasing importance of time to value.
In traditional software contracting, success is often measured against scope, cost, and schedule. While these remain important, they can obscure a more meaningful measure: how quickly a solution delivers real, usable value to the end user or business.
Time to value refers to the elapsed time between starting development and delivering something that creates tangible benefit. This could be a feature that improves user experience, a capability that unlocks revenue, or an operational improvement that reduces cost.
Agile methodologies inherently prioritise time to value by focusing on incremental delivery, early feedback, and continuous improvement. However, traditional contracting models often work against this principle. Fixed price contracts can delay delivery as teams aim to meet a predefined scope, while time and materials contracts can lack the urgency to optimise for speed and impact.
AI is making time to value even more critical. With the ability to prototype, build, and iterate faster than ever before, organisations that can deliver value quickly gain a significant competitive advantage. Conversely, those constrained by rigid contracts or misaligned incentives risk falling behind.
This shift places time to value at the heart of how we should think about contracting. The goal is no longer simply to deliver software, but to deliver the right software, at the right time, in the most efficient way possible.
A fixed price contract is outcome-based. The supplier agrees to deliver a defined scope of work for a predetermined price. This creates a sense of certainty and control, which is particularly attractive to procurement teams.
In competitive tender processes, fixed price can also drive cost efficiency. Suppliers are incentivised to offer attractive pricing in order to win the work. On the surface, this appears to reduce risk for the client.
However, this model assumes that the scope of work can be clearly defined and remain stable throughout the project. In practice, this is rarely the case. Requirements evolve as understanding improves, user feedback is gathered, and technical constraints become clearer.
To accommodate change, formal change requests are typically required. These introduce administrative overhead, slows down decision-making, and can create tension between client and supplier. In some cases, suppliers may rely on change requests as a mechanism to recover margin, particularly if they have underbid initially.
From a time to value perspective, fixed price contracts can be particularly problematic. The focus on delivering a predefined scope can delay the release of valuable features. Teams may prioritise completeness over impact, resulting in longer delivery cycles and slower realisation of benefits.
That said, fixed price contracts still have a role to play. They can be effective for delivering a clearly defined minimum viable product (MVP), where the scope is sufficiently constrained to reduce uncertainty. In these cases, they can help establish trust and provide a structured starting point for a relationship.
At eCreation, we recognise that even well-defined projects evolve as understanding grows. Rather than treating every change as a contractual variation, our fixed price engagements typically include a contingency fund for minor changes and encourage "horse trading" between features, allowing lower-priority work to be replaced by higher-value functionality while keeping the overall scope and cost unchanged. This keeps the focus on delivering the greatest value rather than simply delivering the original specification. Strong project governance, effective product ownership, and disciplined backlog management are essential to ensure this flexibility does not become uncontrolled scope or expectation creep.
Time and materials (T&M) contracts take a different approach. They are resource-based, with clients paying for the time spent and resources used. This model aligns more naturally with Agile delivery, as it allows scope and priorities to evolve without contractual renegotiation.
From a time to value perspective, T&M has clear advantages. It enables teams to focus on delivering value incrementally, rather than adhering to a fixed scope. It also supports continuous reprioritisation, ensuring that the most important work is always addressed first.
However, T&M introduces its own challenges. One of the most significant is the potential misalignment of incentives. Because revenue is tied to time spent, there is no direct financial reward for a supplier to improve efficiency or productivity.
This issue is amplified in an AI-driven environment. As developers become more productive through the use of AI tools, the amount of time required to deliver a given outcome decreases. Under a T&M model, this can result in lower revenue for the supplier, despite higher value delivered to the client.
There are also concerns around quality and consistency. In some cases, clients experience a decline in developer quality over time, as initial high-performing teams are replaced with less experienced resources at the same rate. This can undermine trust and impact delivery outcomes.
Additionally, T&M can reduce the strategic contribution of the supplier. Without the structure of a defined scope, there is a risk that the relationship becomes transactional, focused on providing resources rather than delivering expertise and insight.
At eCreation, we believe the success of a time and materials engagement depends on consistently providing high-quality teams. We maintain a strong pool of experienced engineers through rigorous recruitment, continuous training, and investment in the latest development practices, including AI-assisted software engineering. Rather than viewing developers as interchangeable resources, we regularly review delivery with our clients to ensure the team's size, skills and structure continue to reflect the project's changing requirements. This allows us to maintain productivity, avoid unnecessary cost, and ensure clients continue to receive the level of expertise they expected when the engagement began.
Artificial intelligence is fundamentally reshaping software development. Tools for code generation, automated testing, and intelligent debugging are enabling developers to deliver more in less time. This is not a marginal improvement, but a step change in productivity.
The impact of this is twofold. First, it increases the importance of high-quality developers. Small, highly skilled teams, augmented by AI, can now outperform much larger teams. Second, it introduces greater variability in delivery. Tasks that once required significant effort can now be completed rapidly, while others still demand deep expertise.
This has profound implications for contracting. Time-based models become less meaningful when time itself is no longer a reliable proxy for effort or value. At the same time, the ability to deliver value quickly becomes a key differentiator.
AI also enables faster iteration and experimentation. Ideas can be tested and refined in shorter cycles, allowing organisations to learn and adapt more quickly. This reinforces the importance of contracting models that support flexibility and prioritise time to value.
In this context, the goal of contracting should be to enable and incentivise the efficient delivery of value, rather than simply tracking time or enforcing scope.
Modern software development increasingly involves blended teams, where supplier and client developers work together. This approach offers significant benefits, including knowledge transfer, improved collaboration, and greater long-term sustainability for the client.
Blended teams can accelerate time to value by reducing handoffs, improving communication, and enabling faster decision-making. They also allow clients to build internal capability, reducing dependency on external suppliers over time.
However, traditional contracting models can struggle to accommodate this approach. Fixed price contracts require clear boundaries of responsibility, which can be difficult to maintain in a collaborative environment. Time and materials contracts, meanwhile, can reduce the supplier’s role to simply providing resources.
To fully realise the benefits of blended teams, contracting models must recognise and support collaboration, rather than enforcing rigid separations.
At eCreation, we actively encourage blended delivery teams that integrate client developers alongside our own engineers, rather than limiting customer involvement to the Product Owner alone. We are happy to adapt our commercial models to support this way of working, whether under fixed price or time and materials contracts. Bringing client developers into the team promotes knowledge sharing, reduces dependency on the supplier, and helps clients build their own long-term capability. We also find that working as a single integrated team significantly improves communication, accelerates decision-making, and builds the trust that underpins successful Agile delivery. Ultimately, our objective is not simply to deliver software, but to leave our clients with a stronger, more capable engineering organisation.
Story point-based contracting offers an alternative that aligns more closely with Agile principles and the realities of AI-driven development. In this model, payment is linked to the delivery of software complexity, measured in story points, rather than time spent.
Story points are a relative measure of effort, complexity, and uncertainty. They provide a way to compare work items without relying on precise time estimates. By linking payment to completed story points, the focus shifts from time to output.
This approach has several advantages. It aligns incentives around productivity, encourages efficient delivery, and supports continuous reprioritisation of the backlog. Because the contract is based on output, scope can evolve without requiring renegotiation.
From a time to value perspective, story point contracting is particularly powerful. It enables teams to focus on delivering the most valuable work first, without being constrained by predefined scope or time-based billing. It also allows both client and supplier to benefit from increased productivity, particularly when leveraging AI.
However, this model is not without challenges. Story points are inherently subjective, and there is a risk of inflation if not properly managed. There is also a potential trade-off between speed and quality, which must be addressed through strong governance and a clear definition of done.
A story point is used in Agile development to estimate the relative size of work and help plan how much can be delivered in a sprint. Items in the backlog are assigned story points based on their effort, complexity, and uncertainty. Each team develops a typical “velocity”, the number of points they can complete in a sprint, which guides sprint planning.
A useful analogy is planning a drive for a holiday. Story points are like the distance in miles, not the time it will take. Journey time can vary depending on traffic, weather, or who is driving, but the distance remains consistent. In the same way, story points provide a stable way to compare work, even when delivery conditions change.
For example, fixing a minor bug might be a 1-point task, while building a new feature with integrations and validation might be an 8-point task. Over time, story points become consistent within a team, making them a reliable tool for planning and tracking progress.
While story point-based contracting represents a shift towards output, it still relies on an abstract and sometimes subjective measure. As teams mature, there is an opportunity to move one step further towards truly outcome-based contracting by focusing on throughput.
In well-functioning Agile teams, user stories are written to a consistent standard. When backlog items are properly refined, broken down, and defined, they tend to converge on a similar size. In practice, this means that many tickets represent broadly equivalent units of work, regardless of the specific functionality being delivered.
At this point, the distinction between story points becomes less critical. Instead, productivity can be measured more directly through the number of completed tickets over time. Throughput becomes a practical and observable proxy for value delivery.
This creates the foundation for a more outcome-based contracting model.
At eCreation, we see outcome-based contracting as a natural evolution of Agile delivery. Rather than pricing based on time or even abstract measures of effort, we work with delivery pods (PODs) that have an agreed capability to deliver a defined level of throughput. Each POD is a stable, cross-functional team comprising the skills needed to deliver end-to-end value, including software engineers, QA specialists and product support.
Our focus is on maintaining a consistent and predictable throughput of high-quality work, rather than measuring the hours expended to produce it. By monitoring throughput over time, we can identify changes in productivity, understand their underlying causes and continuously optimise the team's performance. This aligns strongly with our focus on time to value, ensuring that commercial discussions centre on the continuous delivery of customer outcomes rather than the measurement of effort or elapsed time.
A throughput-based model requires clear visibility and active management, but it also creates a more transparent and collaborative framework for both client and supplier.
If productivity falls below an agreed threshold, this should not immediately trigger commercial penalties. Instead, it should initiate a structured retrospective to identify the underlying causes. These may include:
By focusing on root causes, both parties can take corrective action to restore productivity. This reinforces a shared responsibility for delivery, rather than creating adversarial dynamics.
Equally, improvements in throughput should be understood and analysed. Gains may come from better tooling, improved processes, or the effective use of AI to accelerate development and testing. Understanding these drivers is key to sustaining performance over time.
In theory, throughput-based contracts can include mechanisms for bonuses or penalties based on performance against defined thresholds. However, in practice, these are not always necessary, particularly in shorter-term engagements.
For many organisations, including eCreation, the strongest incentive for a supplier is the opportunity to retain and grow the relationship. Consistent delivery, transparency, and continuous improvement are often more effective motivators than contractual penalties.
This is particularly true in an AI-driven environment, where productivity gains can be significant but uneven. Rigid commercial mechanisms can discourage innovation or create unintended behaviours, whereas trust-based relationships allow both parties to benefit from improvements.
The key is to ensure that throughput is measured consistently, and that the factors influencing it are well understood by both client and supplier.
Throughput-based contracting represents a further evolution beyond both time-based and effort-based models. It shifts the focus from how work is done to what is actually delivered, and how consistently value is created. It provides a pathway towards contracts that are better aligned with Agile principles, more resilient to the impact of AI, and more focused on reducing time to value.
Ultimately, the goal is not to optimise for hours or estimates, but to create a delivery model where high-quality teams can operate at their full potential, continuously delivering meaningful outcomes.
In practice, no single contracting model is suitable for all situations. The most effective approach is often a combination of models, tailored to the specific context.
At eCreation, we typically start with fixed price engagements to deliver a well-defined MVP. This provides a structured starting point, builds trust, and establishes ways of working. Once this foundation is in place, we transition to more flexible models.
As relationships mature, there is increasing scope to adopt output-based approaches. These models are particularly well suited to environments where AI is driving productivity gains and rapid iteration is essential.
The key is to remain pragmatic. Contracting should support delivery, not constrain it. It should enable collaboration, encourage innovation, and align incentives around shared goals.
The way we contract for software development is at a turning point. While traditional fixed price and time and materials models remain valuable, they are increasingly being challenged by Agile delivery and the rapid productivity gains enabled by AI.
The focus is shifting from measuring time and effort to minimizing time to value. Outcome-based approaches, particularly those centred on predictable throughput, offer a more effective way to align customers and suppliers around the continuous delivery of business value rather than adherence to a fixed scope or number of hours.
There is no single contract that suits every project, and the most successful organisations will adopt a pragmatic approach, selecting the commercial model that best fits the stage and nature of the engagement.
At eCreation, we believe contracts should enable collaboration, reward productivity, and help high-performing teams deliver their full potential. By focusing on outcomes, throughput, and time to value, commercial models can become an enabler of innovation rather than a constraint on it.
If you are rethinking how you contract for software development, or looking to align your delivery model with Agile and AI-driven productivity, we would be happy to help.
At eCreation, we work with clients to design practical, outcome-focused approaches that improve time to value and unlock the full potential of high-performing teams.
Get in touch to start a conversation about how we can support your next project or help evolve your current delivery model.
Simon Butler
Co-founder and CEO, eCreation
If you want to discuss your latest project or product requirements, or just want regular updates from us, please drop your details in this form. We will respond as soon as we can.
