The software we choose today addresses the needs we understand today. The difficulty comes when a contract changes, a new service takes shape or a customer needs a different process: yesterday’s solution becomes a constraint, and work moves back into spreadsheets and email.
AI makes an interesting possibility more accessible: building and adapting digital tools around the way a business works. The value does not lie in generating code once. It lies in turning new requirements into software that people can use, test and maintain. That is the capability worth looking for when choosing a technology partner.
A product can offer every feature on the checklist and still be difficult to adapt. Can we configure a step, connect another application or add a rule without working around the system? Who takes responsibility when a change affects data and people across departments?
The useful question is not only “which software should we buy?”. It is also “how will we be able to evolve it?”. This shifts attention from a feature catalogue to the ability to support a process over time, keeping what works and changing what needs to improve.
AI can support coding, test preparation, exploration of alternatives and documentation. It can reduce the effort involved in some repetitive tasks and help a team try an idea before investing in a complete solution. Any reduction in time or cost depends on the project, the context available and the checks required.
Engineering decisions remain: defining requirements, choosing an architecture, managing access, integrating systems and checking behaviour. A convincing prototype does not yet demonstrate that an application can support daily operations. AI expands a development team’s tools; it does not remove responsibility for what is released.
There is no need to rebuild accounting, email or every other function already well served by existing products. SaaS can be the most effective choice when it meets the need, integrates with other tools and offers sustainable terms. Custom development makes sense when it addresses a difference that matters to the business.
A hybrid approach is often appropriate: keep the business system and add a dedicated module, connect applications that do not communicate today, or simplify a specific activity. Before deciding, we can compare the options using our guide to upgrading, integrating or replacing business software.
Consider this hypothetical example: a company manufactures made-to-order components. Its business system manages orders and administration, but preparing quotations requires technical information scattered across email and spreadsheets. Every customer revision introduces checks and manual handovers.
Rather than replacing the business system, we can assess a dedicated application for collecting specifications, managing revisions and preparing the information to transfer into the existing system. Pricing rules and approvals remain explicit. AI can assist the team developing the module; using AI inside the module is a separate decision, based on an actual requirement.
When the process changes, the aim is to adjust a rule or a step without starting again. Feasibility also depends on available interfaces and the business system’s terms: integration cannot be assumed.
An ongoing partnership is useful when each intervention makes the system easier to understand and manage. This does not mean the business owner needs to learn programming. It means being able to explain a priority, assess its implications and access the information needed to manage the software over time.
These elements help limit dependency on a particular tool or supplier. Having the code alone does not guarantee independence: someone must be able to understand, test and release it.
The number of lines produced by AI says little about the outcome. For an initial intervention, choose a contained activity and an observable measure: completion time, repeated data entry, corrections or cases that need manual attention.
We also define what must remain stable: permissions, traceable changes, data quality and recovery from errors. Comparing results with the starting point helps us decide whether to improve the module, extend it or stop. There is no need to promise savings before checking how the tool is used.
An application needs maintenance, updates, support and dependency management. AI services can also involve recurring charges and terms of use that need assessment. These factors belong in the comparison with a standard product, alongside the ability to export data and move to a different solution.
The proposition to look for is not “unlimited development at almost no cost”. It is an approach with clear priorities, responsibilities and terms for change. Speed is useful when it produces an improvement we can put to work and continue to manage.
We start with an activity that currently forces a compromise: copied information, a fragmented approval or a function the existing product does not cover. Together we can assess whether to configure what is already there, integrate a component or build tailored business software, using AI where it makes a verifiable contribution.
An AI opportunity assessment can help clarify the scope and the first step. Tell us about the process you would like to improve: the starting point is work that needs to run better, rather than technology that must be added at any cost.
The competitive advantage is not just choosing the right software today. It is having the ability to build and evolve what the business will need tomorrow.
Microsoft Research’s study of software developers observes productivity benefits in the settings studied; it is not an estimate for every project. The DORA AI Capabilities Model explores capabilities that help organisations obtain value from AI. These inform the approach, rather than promise results for an individual business.
