Irina Shymko | CEO at Langate EMEA | Introducing innovations and transforming business in Europe/America | Lecturer, mentor, advisor.
For years, the software decision for most small and midsize businesses was straightforward: buy, don’t build. The economics favored SaaS. Building a custom system meant assembling developers, business analysts, QA engineers and other specialists, then investing months of work before knowing whether the product would deliver enough value. Paying a subscription for an existing platform was the rational alternative.
The compromise was that businesses had to adapt their processes to software designed for thousands of other companies. The important shift is not that AI can generate code faster. It is that the cost of turning a well-defined business process into working software is falling. For businesses with specialized workflows, this changes what’s worth building and how they invest in technology.
Look for the workflow, not the product.
A common response to an operational problem is to search for better software. Consider a company where an employee receives a customer request, checks data in a CRM, copies information into another system, calculates it in Excel, requests approval, updates the CRM and generates a document.
The company might blame the CRM. But the CRM may not be the problem. The expensive part is the human coordination happening between systems. Instead of replacing an entire platform, an AI-assisted team could build a lightweight operational layer that retrieves the necessary data through APIs, applies business rules, triggers human approval for defined exceptions and updates the relevant systems. That is a much smaller engineering problem.
This suggests a practical rule: Don’t start by asking what software to build. Start by finding an expensive workflow. One useful way to evaluate candidates is to estimate their annual cost: (frequency x time per instance x loaded labor cost) + (frequency x error rate x cost per error) + cost of delays.
A 20-minute manual process performed twice a month probably does not justify development. The same process performed hundreds of times per week may. Technology investment should be compared with the cost of the current process, not with zero.
AI makes domain knowledge more valuable.
AI can generate interfaces, application logic, tests, documentation and assist with integrations and debugging. What it cannot do is resolve ambiguity in an unclear business process.
For example, a developer needs to know what should happen when an order reaches a particular status, which values to retrieve, when an approval is required and what actions to take next. AI can help translate those requirements into working software, but someone must first define the rules and exceptions.
This creates a new development equation: domain knowledge, technical literacy, AI acceleration and engineering judgment. A domain expert does not need to become a cloud architect, but basic technical literacy can make AI-assisted development far more effective. Engineering expertise remains essential as software moves toward production, particularly when security, sensitive data, complex integrations, reliability and scale enter the equation.
AI is lowering the cost of being wrong.
AI is lowering not only development costs, but also the cost of testing whether an idea is worth building. Consider a midsize company evaluating employee benefits software. After researching the market, shortlisting two SaaS products and mapping them against its workflows, the team faced a familiar problem: another tool with per-user costs that would grow with the company, while about 5% of its functionality was needed.
Instead, the CTO translated the HR requirements into a focused internal system and built the first working version in three days using AI-assisted development. After two weeks of testing, the team could identify gaps, refine the system and prepare it for employee use.
The lesson is not to replace SaaS by default. It is that AI can make testing the alternative inexpensive enough to factor into the buy-versus-build decision, and provide evidence before a larger investment.
Build the differentiation, not the infrastructure.
Cheaper development creates another risk: building what you should have bought. Most companies do not need proprietary authentication, cloud storage, email delivery or payment infrastructure. Mature services solve these problems. A more efficient architecture often combines them.
Buy the commodity. Build the differentiation. Connect the rest. For a logistics business, differentiation might be exception-handling logic. For a specialty healthcare organization, it might be a specific operational workflow. For a manufacturer, it could be quoting or production-planning logic.
APIs and managed cloud services can provide the commodity infrastructure while a smaller custom layer implements the business-specific logic. This is where AI can create disproportionate value for smaller companies, not by rebuilding their entire technology stack, but by making the unique 10% economically feasible to build.
Factor maintenance and ownership into the build decision.
Custom software still requires updates, security monitoring, infrastructure management and someone accountable for its long-term reliability. AI can reduce some of that effort, but it does not eliminate it. The business case should therefore compare the total cost of ownership, not just the initial build cost, with the long-term cost and constraints of SaaS.
Make every development stage earn the next one.
For leaders considering this approach, the investment process can be simple:
1. Identify one repetitive, expensive workflow.
2. Quantify its current cost, including human effort, errors and delays.
3. Define the desired process independently of current software limitations.
4. Reduce the scope to the smallest version capable of testing the hypothesis.
5. Use AI-assisted development to shorten the build-test-learn cycle.
6. Measure adoption, time saved, errors reduced and business impact before expanding.
The result may be another SaaS purchase. It may be an integration between existing systems. Or it may justify building proprietary software. The point is not to build more. It is to make smaller technology bets and obtain evidence sooner.
SaaS became dominant partly because buying software was convenient while building it was expensive. AI does not make SaaS obsolete. But it is weakening the assumption that adapting the business to existing software will always be cheaper than adapting software to the business. For some small and specialized companies, that may fundamentally change where the next technology dollar should go.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?