.webp)
When I talk to procurement teams at large organisations about potential collaboration, the same question comes up sooner or later: What are your manday rates?
Yes, for a long time, it was a sensible way to compare vendors and keep costs in check. But in 2026, it is a bit like buying a car and asking how much the welder on the assembly line earns per hour. Relevant information, perhaps. Just not the right question.
And then comes the follow-up, which is worse.
If AI does 20% of your work, can we pay 20% less?
This is not a caricature. It is the current reality we encounter with some of the largest players in the market. Traditional banks, industrial leaders, large enterprise organisations with entire procurement departments and approved vendor policies.
The logic seems straightforward: AI speeds up development, so work takes less time, so developers should charge less. The problem is that this assumes AI simply does the same work faster. That is precisely the misunderstanding that will cause real difficulties down the line.
We are not getting a cheaper developer. We are getting a different deliverable.
A few years ago, software delivery was relatively linear: a client described what they wanted, a vendor designed the architecture, wrote the code, deployed it, handed it over, done. Then came agile development. But you paid for developer time in both cases and it made sense.
AI is changing this structurally. Increasingly, what gets delivered is outcomes, not hours. AI agents handle parts of the work autonomously, generating code, testing, refactoring, documenting.
But someone still needs to design those agents, configure them, monitor their outputs, and take responsibility for what they produce. Someone to decide architecture of the whole system, someone who makes product decisions.
The hours that used to go into writing routine code do not disappear from the invoice. They get reallocated to architectural review, to quality gates, to making sure the AI-generated output does not introduce subtle security gaps or structural problems that will not show up until the system is under real load. More on this is also covered in The Shift to AI-Accelerated Software from last year.
What previously required one junior position now often demands a senior architect who understands both the domain logic and the ways AI agents fail when they lack proper guardrails.
There is also another significant cost that vendors now carry. Tokens, licences, infrastructure for AI agents, we pay for all of it, and in the world of manday rates it never existed.
If an organisation successfully negotiates a 20% reduction in manday rates but ends up with a team that lacks the capacity to work responsibly with AI tools, they have not bought the same thing more cheaply. They have bought a worse outcome at a price that looks attractive on paper.
What happens to organisations that stay stuck in the old model
I understand why procurement optimises for cost. That is the job. But optimising for manday rates while the deliverable itself is shifting means ending up with the right price for the wrong thing.
Vendors who agree to those terms will find a way to make them work, usually by leaning on more junior people, or quietly stopping investment in their own AI capabilities because the margins simply do not support it.
The consequences are not always immediate, and that is part of the problem. AI can generate a working application remarkably fast. The initial launch looks clean, the cost looks controlled, and everyone moves on.
The real bill arrives two or three years later, when the system starts struggling under scale, when a security update reveals architectural decisions nobody would have made with proper senior oversight, when the technical debt that was invisible at launch becomes the thing blocking every new feature. More on this in Mobile Banking Apps Don't Break at Launch. They Break Years Later.
Software is no longer a project you build, ship and maintain at low cost. It is infrastructure, as critical to the business as the systems it runs on.
The organisations that procure it accordingly will build digital foundations that hold. Those that keep optimising for the cheapest available manday will keep rebuilding the same things, slightly differently, every few years.
What a more useful conversation actually looks like
None of this means procurement should stop asking questions. It means asking different ones.
Rather than "what is your manday rate," the more interesting questions are:
- How do we measure success twelve months from now?
- How will the team composition evolve as we integrate AI into our processes?
- How do you take responsibility for outcomes, not just outputs?
That last one matters most. A vendor who commits to outputs, hours logged, features shipped, tickets closed, has a fundamentally different relationship with risk than one who shares accountability for whether the product actually performs.
The first will deliver exactly what was specified and walk away. The second does not disappear when the project closes.
The question about manday rates will not disappear overnight, nor should it. But the more important question is simple: what are we actually buying, and how will we know it is working?
.webp)
.webp)
.webp)
.webp)
.jpg)
.jpg)
.png)
.avif)
.avif)
