If Next Year’s Software Budget Stays Flat, What Should Businesses Change Now?

1. Start with business impact, not a list of technology requests

Yes, we have customers whose software and support needs are growing while their budgets remain essentially flat.

The most productive conversations do not begin by asking which projects we can squeeze into the existing budget. They begin by identifying which initiatives have the greatest business impact.

We typically look at priorities such as revenue generation, customer experience, productivity, operational efficiency, risk reduction and business continuity.

If a company has five software initiatives it would like to fund but can realistically complete only two, the question should not simply be which two are easiest to build. It should be which two create the greatest measurable value for the business.

This is also where we increasingly bring engineers into the conversation earlier. An experienced engineering team can find ways to achieve substantially more within the same budget by changing the technical approach. AI-assisted development, automation, reusable components, improved architecture, better testing practices and modernization strategies can all affect the amount of business functionality a team can deliver.

The objective is not simply to make developers work faster. It is to determine whether technology can change the economics of the initiative.

2. A flat budget does not mean every project should be reduced equally

One mistake I see organizations make is applying a percentage reduction across every technology initiative. If the budget is reduced by 10%, for example, the organization may assume every project should simply become 10% smaller. That can be the wrong approach.

Some initiatives are directly tied to revenue or productivity. Others may be necessary to maintain an existing platform. Others may be valuable but discretionary and some may no longer make sense at all.

A constrained budget is therefore an opportunity to create clearer categories:

• Fund - initiatives with a strong connection to revenue, productivity, customer experience, risk reduction or strategic growth.
• Optimize - initiatives that remain important but can be delivered differently, phased or accelerated through better technology choices.
• Postpone - initiatives that have value but do not have sufficient near-term business impact to justify available capacity.
• Stop - initiatives where expected value no longer justifies the cost or where the business need has changed.

Sometimes the best way to protect an important project is to stop funding something else.

3. AI should help companies get more from the budget, not simply create another budget category

AI is now part of nearly every software investment conversation I have with customers.

The question is increasingly whether AI should reduce software development costs, increase productivity, improve the end product, or ideally accomplish all three.

My answer is that customers should be careful about treating AI as an automatic cost reduction. AI can accelerate software development, testing, documentation, analysis and other activities. DORA’s research shows that developers using generative AI report higher productivity and satisfaction, while also emphasizing that organizations need strong software delivery fundamentals and governance to turn that potential into broader organizational benefit.

I would ask a development partner to demonstrate exactly where AI is being used and what business benefit it creates:

• Is AI reducing the time required to produce and test quality software?
• Is it improving test coverage or defect detection?
• Is it accelerating requirements analysis or documentation?
• Is it helping engineers understand and modernize legacy code?
• Is it reducing repetitive development work?
• Is it enabling the team to deliver additional functionality with quality without increasing the overall budget?

The important point is that AI should show up in the economics and outcomes of the engagement, not simply in a slide deck.

4. Be careful about switching providers just to save on the hourly rate

Budget pressure naturally causes companies to look at their development partners and ask whether they can get the same work done for less.

We have had customers discuss renegotiating rates, reducing team sizes or evaluating alternative providers because their budgets were under pressure. Those are reasonable discussions. But the quoted hourly rate is only one part of the economics.

Before changing providers, I recommend looking at the full transition cost:

• How much business and technical knowledge will leave with the current team?
• How long will a new team need to understand the application and architecture?
• Who will document undocumented business rules?
• What productivity will be lost during the transition?
• What quality or delivery risk could be introduced?
• Will the new provider require additional management from your internal team?
• What happens to the existing roadmap during the transition?
• Will a lower rate actually produce a lower total cost or just lower the quality levels?

A provider with a higher hourly rate can sometimes have a lower overall cost if the team is more productive, requires less oversight, understands the business better and delivers with fewer defects or delays.

The right comparison is therefore not simply rate versus rate. It is total cost and business outcome versus total cost and business outcome.

5. Budget transparency becomes more valuable as the relationship matures

Budget discussions are interesting because new customers and established customers often approach them very differently.

New customers are understandably cautious about sharing a specific budget before they understand a provider’s pricing model and approach. They may worry that revealing the budget will cause the proposal to be priced up to that number. I understand that concern.

My recommendation is to first ask a potential partner to explain its pricing model, team structure, assumptions and range of likely investment. Once there is transparency on both sides, a budget conversation becomes much more productive.

With long-term customers, the dynamic is different. Once trust has been established, customers are generally much more comfortable sharing their budget, development roadmap and business priorities. That allows the provider to help them make trade-offs before the budget is committed.

The goal is not to spend the entire budget. The goal is to utilize the budget to produce the greatest possible business value.

6. Fixed-price contracts can provide predictability—but they do not remove uncertainty

We have also had customers ask to move from time-and-materials engagements to fixed-price contracts because they need tighter budget control.

A fixed-price model can provide useful predictability when the scope is sufficiently understood and clear. But it is not a solution to uncertainty by itself.

The more complex the project, the more important it is to define the requirements, assumptions, acceptance criteria, dependencies and change process before committing to a fixed price.

The important thing is to match the commercial model to the level of uncertainty. I would rather have an honest conversation about what is known and unknown than put an artificially precise price on a project whose requirements are still changing.

7. Before finalizing a constrained 2027 software budget, ask what should change—not just what should fit

If I were advising a business leader preparing a flat software budget for 2027, I would recommend doing six things before finalizing the plan.

1. 1. Rank initiatives by measurable business impact

   Put revenue, productivity, customer experience, risk, compliance and strategic importance ahead of internal preference or historical momentum.

2. 2. Identify what can be simplified

   Not every requirement needs to be included in the first release. Look for features, integrations and workflows that can be phased without undermining the core business outcome.

3. 3. Look for opportunities to use AI to increase delivery capacity

   Do not simply ask whether a provider uses AI. Ask where it is being used, how it is governed, what productivity improvements have been observed and how those improvements affect your cost or delivery timeline.

4. 4. Review the economics of your current development model

   Look beyond hourly rates. Evaluate productivity, quality, team stability, knowledge retention, management overhead, delivery predictability and the cost of changing providers.

5. 5. Decide what you are willing to stop

   A constrained budget requires subtraction. If every initiative remains a priority, nothing is really prioritized.

6. 6. Build a roadmap around outcomes, not just projects

   A good 2027 technology roadmap should make it clear what the business expects to accomplish, how success will be measured and what sequence of investments is required to get there.