The New Advantage That May Reshape Your Industry
By Marcie D. Terman, DATAFORT founder
A transition is coming in how businesses organise their work. Nimble companies led by innovative founders can increasingly choose to scope, design, develop and deploy software around how they want to operate. Professional AI-assisted development is making that choice commercially realistic for more businesses, reducing the need to squeeze their operations into standard packages or fund lengthy, expensive customisation projects.
That shift has competitive consequences. Better processes can strengthen margins, create a better working environment and give employees more time for customers by reducing repetitive administration. Businesses that make this transition successfully have an opportunity to pull ahead of competitors.
There is already evidence of purchasing decisions changing. In McKinsey’s August 2026 global AI survey, 32% of respondents said their organisations had decided against buying at least one software product or feature because they could build the functionality internally using AI coding agents.
The same report found that nearly three-quarters of organisations it classified as AI high performers reported fundamentally redesigning workflows, compared with approximately one-quarter of other respondents. That association supports a broader proposition: the opportunity extends to changing how work gets done.
McKinsey’s purchasing finding concerns internal development. Businesses without an internal team can explore the same opportunity through an experienced development partner. That brings the build-versus-buy question within reach of companies that may previously have dismissed bespoke software as too expensive or difficult to manage.
How better processes change who wins
Consider what happens when your team can produce a more accurate quotation sooner, start work without chasing the same information twice and issue an accurate invoice as soon as the job is complete. Customers receive a better service. Employees spend less time correcting mistakes and handling repetitive administration. The business can take on more work without overheads rising at the same rate.
Those improvements give management choices: protect margins, compete more effectively on price, invest in service or pursue growth that existing capacity would have ruled out. Clearer, more current information also helps managers make better decisions. The advantage comes from choosing the right processes to improve and implementing the changes well.
The cost of fitting the business to the software
I recently spoke with a company in business finance, where extensive paperwork, validation and checking are part of daily operations. It was two years into a project to integrate a CRM system with its business processes, working with a consultant, and the integration was still unfinished. Even once complete, the underlying CRM would remain a licensed product. If the supplier later increased its fees substantially, the time and effort invested in implementation would make switching a difficult commercial decision.
When my own company moved away from a SaaS CRM whose costs grew with each additional employee, we had a basic replacement up and running in weeks. We have since been able to develop, test and deploy some additions in days. The initial scope was limited, and more complex projects will take longer. What changed was our ability to adapt the system around our own priorities.
What has changed in the economics of development
Professional development teams can now use AI to help produce code, explore alternatives, build prototypes, generate tests and prepare documentation. Integration with existing systems can use APIs, automated notifications or custom connectors, depending on what those systems support. Their limitations still need to be assessed at the outset.
The benefit extends beyond faster coding. Earlier prototypes let employees test assumptions before too much time and money has been committed. A team can discover that a proposed screen misses an essential exception, or that a different sequence removes an unnecessary approval, while changes are still relatively inexpensive.
The amount saved will depend on the project, the existing systems and the team’s experience. But the commercial question has changed. A tailored solution that once looked impractical may now deserve serious evaluation.
Software developed using AI need not contain AI. A system that routes work, applies fixed rules or connects databases may run perfectly well without a language model. Professional judgement includes deciding where conventional software is sufficient, avoiding unnecessary complexity and ongoing model charges.
Fast coding still needs professional engineering
Tools such as Cursor and Claude Code can make it tempting to assume that generating a working application means you can safely build your own business system. That is a risky leap. Coding is only part of the work: understanding business processes, integrating systems and, critically, protecting data all require expertise. The ease of producing a prototype can hide the difficulty of making it dependable.
Business software must work with real data, imperfect inputs, unusual cases and people who use it differently from its designers. It must also fit the systems around it and protect information appropriately.
That requires experienced people to design the architecture, review code, test integrations and control who can see or change information. Changes need to be recorded and tested before deployment into production. Monitoring, audit records, backups, recovery and maintenance need clear owners. Security testing, including penetration testing where appropriate, belongs in the delivery process.
AI coding tools sit inside that professional environment. Their output must be examined and verified. A development partner should be able to explain how your system will be tested, supported and recovered if something goes wrong, with the same clarity used to explain what it will do.
The bridge between business and software
Before anyone builds a solution, someone must understand the business well enough to specify the right one. This is often the function of a Forward Deployed Engineer, or FDE: a technical professional who works closely with the client to connect business problems with practical software delivery. (https://blog.palantir.com/)
The work begins with questions. Where does information enter the business? Who checks it? What happens when something is missing? Which decisions require experience or authority? Where does work wait, and why?
The answers should shape both the process and the software. An approval introduced years ago may no longer serve a purpose. A repeated check may exist only because two systems hold conflicting information. Automating those activities without examining them would preserve avoidable work.
A capable development partner combines this operational understanding with engineering experience. For a mid-sized company, that offers access to the FDE function without having to recruit and retain a full-time specialist.
Build around what makes your business better
The sensible starting point is to keep the systems that serve you well. An accounting package, payroll platform or other specialist product may already perform its role effectively. Sometimes better configuration or an existing integration is all that is needed. Development becomes interesting where an important gap remains.
As an illustration, imagine a service company whose enquiries, quotations, scheduling, job records and invoices sit in separate systems. Staff repeatedly transfer details, chase updates and check whether completed work is ready to bill.
A tailored application could connect those stages using the company’s own rules. An accepted quotation could create a job with the required information. Missing details could be flagged to the responsible person. Completion could prompt invoice preparation, with staff retaining approval where needed. Its existing accounting system could remain in place.
The resulting value would come from shorter delays, fewer omissions and a clearer view of work in progress. That is the practical test for bespoke software: whether it enables better execution of something that matters commercially.
The architecture behind the solution
For systems that use AI, choosing the model is a commercial, technical and security decision. A leading commercial model accessed through an API may offer the right capability with relatively little infrastructure to manage. An open-weight model can instead be deployed on your own or privately hosted servers, giving you greater control over where data is processed. While open-weight models make their learned parameters available, this does not automatically mean every aspect of their training pipeline or dataset is open source.
A partner that can work with both approaches has more options. Where justified and permitted by the licence, it can fine-tune an open model, adjusting its learned parameters for a specific task. That can improve suitability, but it does not guarantee better results or enforce security boundaries. Hosted usage charges must be weighed against the infrastructure, maintenance and specialist skills required to run a model privately.
Sensitive data requires care with either approach. The design should minimise what is shared and assess access, retention, hosting location and the provider’s terms. Removing identifiers or hashing them may reduce exposure, but hashing alone does not establish anonymity: people may still be identifiable from other information. Pseudonymised data remains personal data under UK GDPR. Private hosting gives greater control only when the surrounding application, connections and access controls are properly secured.
Agentic systems add another possibility: AI that can carry out a sequence of tasks through connected tools. With the appropriate permissions, an agent might check incoming documents, identify missing information, prepare a request and update the case record. This can reduce repeated handovers and help staff concentrate on exceptions and customer decisions.
The ability to act also increases the consequences of mistakes or malicious instructions hidden in incoming material. Access should be limited to what the task requires, with technical controls, human approval for consequential actions, activity logs and a way to stop the system. These controls need testing alongside the model’s performance.
Ownership, payment options and the real economics
Commissioning software gives you an opportunity to negotiate control over the application, its business logic and future development. The agreement should make clear what you own, what remains licensed and how you can access your data. Documentation, source-code access where agreed and the ability to change support providers matter too; control should remain practical after the original project ends.
The financial comparison needs to include development, migration, staff adoption, hosting, integrations, security, maintenance and any AI usage. Compare those costs with the existing software bill and the operational work you expect to remove. Time released creates financial value when the business can use it productively or avoid expenditure it would otherwise incur.
McKinsey’s survey provides a useful reminder of that distinction: only 37% of respondents reported a positive impact from AI on earnings before interest and tax across their organisation. Returns need to be measured.
How development is paid for can change as well. Outright purchase remains an option, while incremental payment structures can spread the commitment. Possible arrangements include:
- Staged payments linked to agreed milestones or accepted deliverables.
- Instalments that spread the agreed development price over a defined period.
- Leasing, with software usage rights and any eventual ownership specified in the agreement.
- Business loans that fund development, with repayments made to the lender.
Availability depends on the developer, client, project and any finance provider’s requirements. Payment arrangements should be considered alongside total cost, ownership and ongoing support obligations. Spreading expenditure can improve affordability; the project still needs a sound business case.
The benefit of staying adaptable
AI models continue to change, and the best choice for a particular task can change with them. For a customer-facing system, a newer model might provide more accurate answers, faster responses or a lower cost per interaction. A development partner with an active research capability can evaluate those possibilities against your real requirements, including customer experience and data protection.
Designing the application so its model can be replaced helps preserve that choice. Each proposed change still needs testing against representative tasks, security requirements and operating costs, followed by a controlled rollout with a way to revert. The value of research is knowing when a change produces a worthwhile improvement and when the existing model remains the better choice.
Start with a measurable business opportunity
Start with the part of the business causing you and your team real grief: a recurring bottleneck, an unreliable handover or a connected set of activities that consumes too much time. Map how work moves today and establish a baseline for staff time, delays, errors, cost and capacity. Agree what a worthwhile result would look like before development begins.
A contained pilot can then test the proposed solution with the people who will use it. Short development cycles allow them to see progress, challenge assumptions and refine how it works. Integration, security testing and support should be included from the start, with agreed checks completed before production use. Give the team time and training to become comfortable with the new process.
Once the system is in use, measure the result: faster turnaround, fewer unresolved exceptions, reduced administration or greater capacity. Expand into adjacent activities when the evidence supports it, using what the team has learned. This makes the transition manageable and gives each further investment a clear purpose.
A different way to compete
The build-versus-buy decision is becoming a management question with competitive consequences. Leaders have more reason to examine whether software is supporting their ambitions or limiting what the business can do. Those who act intelligently can turn their operational knowledge into systems that help them deliver better service and stronger commercial results.
At DATAFORT, established in 2000, we bring together business understanding, security experience and professional development, supported by our UAE-based research arm’s evaluation of emerging AI models. Gavin Smith’s more than 20 years of machine-learning development, including work for banks, inform an approach that starts with the client’s objectives and uses the appropriate technology to deliver them.
Where is your software slowing your business down?
Book a 15-minute conversation with DATAFORT to explore whether a contained development project could make a measurable difference.
