The SMB
Competitive Reset
For years, scale gave large organisations capabilities that smaller businesses could not economically reproduce. AI-assisted development is beginning to change that equation — for both sides.
This article is about the changing economics of competition: cost-to-serve, internal software development, capability per employee, build-vs-buy decisions and how an SMB can respond without starting a transformation programme.
The competitive floor is moving.
Large businesses can increasingly behave smaller. Small businesses can increasingly behave bigger. The shift is not universal, but falling build and service effort can change which opportunities are economically viable.
Can increasingly behave smaller
Can increasingly behave bigger
AI matters here because it can reduce friction in places that conventional software found difficult: interpreting unstructured requests, assisting software development, producing first-pass content or analysis, and helping employees navigate information more quickly.
None of those changes automatically makes a market attractive. Pricing, distribution, regulation, brand, channel economics and strategy still matter. But when the cost of building and operating capability falls, the minimum economically interesting opportunity can move too.
This is the part of the AI discussion that is easy to miss if the conversation stays focused on chatbots or individual productivity. The strategic effect can be a change in which customers and workflows are economically reachable.
What is changing — and what should an SMB do about it?
AI-assisted development adds another viable path for selected problems.
The point is not that companies stop buying software. The threshold for when building becomes worth considering is moving.
AI-assisted development can alter what an enterprise chooses to purchase.
The McKinsey State of AI 2026 finding that 32% of respondents said their organisation had forgone at least one software purchase or feature because agentic coding enabled internal development is important for another reason.
Large organisations already have infrastructure, security patterns, data platforms, engineering teams and procurement processes. Historically, even with those assets, buying an external product could be much faster than building a specialised capability internally.
AI-assisted development can change the threshold.
This does not mean large companies stop buying software, using consultants or working with implementation partners. Commodity platforms, specialist products, external expertise and delivery capacity remain valuable. The point is that the boundary between “we must buy this” and “we can build enough of this ourselves” is shifting for some use cases.
For a services business selling to enterprises, that can affect demand. For an SMB competing with enterprises, it can affect how quickly the larger competitor improves its own operation.
Customers benchmark the experience, not the size of your company.
A customer rarely discounts a poor experience because the supplier has fewer employees. They experience whether they can get an answer, understand the status of an order, receive a proposal, resolve an issue or complete a transaction without unnecessary friction.
As more companies improve those experiences, the minimum acceptable level of operating capability rises.
How quickly can the business acknowledge, understand and act on an incoming request?
Can the customer and team see what is happening without chasing someone for an update?
Does the result depend on who happens to be working that day?
Which parts of the experience can continue even when a specific employee is unavailable?
The threat is therefore not “a competitor has AI.” The threat is that a competitor uses new technology to create a noticeably better operating strength.
Two companies can subscribe to the same AI tools and remain operationally very different. One may use AI occasionally for drafting or research. The other may use technology to make a specific customer journey faster, more consistent and easier to manage. The competitive difference is the resulting capability, not the tool licence.
Size is losing some of its monopoly on capability.
The same forces that can help a large organisation operate with less friction can help an SMB acquire capabilities that were once expensive to reproduce.
A smaller company may not have a sales-operations department, a reporting team, a workflow engineering group and a large internal technology organisation. It may not need all of them. A carefully designed combination of existing software, targeted development, automation and AI can provide portions of those capabilities without reproducing the organisation chart of an enterprise.
Same-sized team. Different operating capacity.
Technology does not make the team bigger. It reduces how much routine coordination the team has to carry.
People carry the operating load
- Routine coordination sits with individuals
- Information is spread across tools
- Follow-ups depend on memory
- More volume creates more administration
People focus on the work that needs them
- Routine actions can happen automatically
- Relevant information is easier to surface
- Exceptions are directed to the right person
- The same team can absorb more activity
What “capability per employee” can look like in practice
Imagine a 20-person B2B distributor receiving around 50 customer enquiries a day. The competitive difference is not the number of employees. It is how much coordination sits around every enquiry.
20
PEOPLE
The numbers above are illustrative, not YANC client results. The point is to baseline the current process and agree the target before judging the technology.
SMBs may also have structural advantages when implementing change: fewer approval layers, fewer legacy systems, shorter feedback loops and direct access to the people who actually perform the work. Those advantages are not universal, but where they exist they can shorten the distance from decision to adoption.
That is why waiting for technology to become “settled” carries its own risk. The objective is not to chase every model release. It is to build the organisational muscle to identify a valuable problem, test a solution and adopt what works.
Don't ask where to use AI. Ask where capability is holding the business back.
The easiest way to waste money is to start with a technology category and then search for somewhere to put it.
A stronger starting point is a constraint that is already visible in the business. The constraint should matter commercially or operationally even if AI did not exist.
Look for waiting, uncertainty, repeated questions, manual status checks or inconsistent responses.
Look for activities that become materially harder each time volume rises.
Look for work that stalls when one experienced employee is unavailable.
This may reveal a cost-to-serve problem rather than a demand problem.
This forces the discussion away from internal efficiency alone and toward competitive capability.
Once the constraint is clear, technology choices become easier. The business can evaluate alternatives against an outcome instead of evaluating products against feature lists.
Better capability does not mean removing judgement.
There is a difference between reducing unnecessary human effort and removing human responsibility.
For many SMBs, relationships, specialist judgement and trust are part of the product. Automating those indiscriminately can destroy the very advantage the technology was supposed to strengthen.
Preparing information, monitoring routine conditions, producing first-pass analysis, checking completeness, coordinating standard actions, surfacing exceptions and maintaining visibility.
Material commercial decisions, negotiation, sensitive customer conversations, unusual exceptions, relationship ownership and decisions where accountability matters.
The design question is therefore not “human or AI?” It is: where should technology increase the quality and capacity of human decision-making, and where can it safely handle the surrounding work?
Presentations show an idea. Working demos expose the idea to reality.
A presentation is useful for aligning people around a concept. It is poor evidence that a solution will work.
A working visual demo has a different purpose. It gives users something concrete enough to challenge. Does the proposed flow match how the business actually operates? Is important context missing? Does the user understand what the system is doing? What happens when the normal path fails?
A useful working demo should answer five questions
WHAT GOES IN?
WHAT HAPPENS?
WHAT DOES THE USER SEE?
WHERE CAN IT FAIL?
WHO DECIDES?
The point is not polished theatre. The point is to make assumptions visible before the expensive part of implementation begins.
This is also why a demo should not pretend to be production. Security, resilience, monitoring, permissions, auditability, integration quality and operational support all require deeper work. A good demo makes the concept testable; it does not erase the work required to deploy it responsibly.
Demo, proof of concept, pilot and production are not the same thing.
Make it visible
Show the proposed workflow and experience with representative inputs.
Test feasibility
Validate the uncertain technical assumptions that could make the idea fail.
Test in context
Use controlled real-world scope to learn about users, exceptions and outcomes.
Operate reliably
Engineer for security, integration, governance, monitoring, support and scale.
Confusing these stages creates two opposite mistakes. One is over-engineering an idea before anyone knows whether users want it. The other is treating a convincing prototype as though it were ready to run a critical business process.
Not every problem needs custom software.
As development becomes easier, the temptation can swing too far toward building. That is no better than automatically buying another SaaS product.
A mature product already solves it well and differentiation is low.
You have internal delivery capacity and control of the capability matters.
You need design, integration or delivery capability that cannot be prioritised internally.
Use established products for commodity functions and add targeted integration, automation or custom capability around them.
The right answer may change over time. A demo built with a partner can become a pilot. A pilot can reveal that an off-the-shelf product is sufficient. A purchased platform may still need targeted integration. The decision should follow the economics and strategic importance of the capability.
Use 90 days to reduce uncertainty — not promise transformation.
Ninety days is not a universal implementation timeline. Some problems are smaller; regulated or deeply integrated systems can take much longer. But it is a useful planning horizon for turning one well-defined constraint into evidence.
Define
Choose one constraint. Establish baseline performance. Identify users, systems, data, decision rights and failure conditions.
Demonstrate
Build enough of the proposed capability to expose the workflow. Test representative normal cases and difficult exceptions.
Prove
Where appropriate, run controlled real use. Measure outcomes, identify controls and decide whether to stop, change or scale.
Baseline before you build
A team trying to improve quotation turnaround, for example, should capture today's reality before changing it: median turnaround, number of touches, rework, approval delay, lost or abandoned opportunities, and how much variation exists between employees.
The target should describe the business outcome, not the technology. “Deploy an AI quotation agent” is a build target. “Make standard quotations available for approval within two hours while preserving commercial approval” is a business target.
A successful implementation should change something the business can observe.
Counting prompts, model calls or automated steps may help operate a system, but they are weak measures of business value.
| Measure | Question | Example |
|---|---|---|
| Customer outcome | Did the experience improve? | Response time, completion rate, resolution time |
| Operating effort | Did the work become easier to deliver? | Touches, preparation time, rework, escalations |
| Commercial effect | Did capability change economics? | Conversion, cost-to-serve, capacity, margin |
| Quality & control | Did reliability improve or deteriorate? | Error rate, exception rate, approval accuracy |
| Adoption | Is the capability actually being used? | Active users, abandonment, manual workarounds |
Some benefits will be indirect. A faster response may improve conversion. Better visibility may reduce management time. More consistent preparation may reduce risk. The important discipline is to decide what evidence would justify the next investment before making that investment.
Access to technology is not the same as execution capability.
Powerful tools are widely accessible. That does not mean an SMB automatically knows which problem to choose, how to integrate the solution, how to govern it or how to get people to use it.
of small-business respondents in Goldman Sachs' survey said AI would be essential to their business within five years.
Source: Goldman Sachs 10,000 Small Businesses ↗reported difficulty choosing the right AI tools for their business.
Source: Goldman Sachs ↗cited lack of technical expertise as a challenge.
Source: Goldman Sachs ↗OECD research similarly finds lower AI adoption among SMEs than large firms and highlights prerequisites including connectivity, data and compute, skills and finance. Source: OECD · AI adoption by SMEs ↗
Reduce the distance from business problem to evidence.
An SMB does not necessarily need a permanent internal team for every emerging technology. But it does need enough ownership to avoid becoming dependent on whichever vendor happens to arrive with the best presentation.
Translate a broad ambition into a specific constraint, outcome and testable hypothesis.
Understand what can remain, what needs connecting and what genuinely needs to be built.
Use working demos and technical proofs to expose assumptions before major commitment.
Address security, permissions, integration, controls, support and maintainability once the idea earns the right to scale.
A good partner should also be willing to conclude that the business should buy an existing product, simplify the process before adding technology, or stop an idea that does not survive testing.
Working examples are more useful than another promise.
YANC's public demos use fictional sample data and illustrative figures. They are not client case studies. Their purpose is to make different operating strengths visible enough to explore and challenge.
Try the demo →
Try the demo →
Demo figures are illustrative examples based on typical small and mid-sized businesses, not client results.
Being small is still an advantage. Being capability-constrained does not have to be.
Large organisations will continue to have advantages of capital, distribution, data, brand and specialist talent. SMBs will continue to have advantages of focus, proximity to customers, speed and specialisation.
AI does not erase those differences.
What it can change is the amount of organisational machinery required to create a useful capability. That is why the strategic question is bigger than “Should we adopt AI?”
The better question is: which capability will matter to our competitiveness twelve months from now, and what is the smallest credible way to prove it today?
Choose the problem. Understand its economics. Decide whether to buy, build, partner or combine them. Make the proposed solution visible. Test the difficult assumptions. Measure what changes. Scale only what earns the next investment.
That is a much more durable response to the competitive reset than chasing whichever technology happens to be generating the most attention.
Start with one capability that matters.
Explore the working examples. If your process is different, bring one business constraint. YANC can help map the economics, decide the right build/buy/partner path and make the proposed solution tangible before a larger commitment.
Business problem first · evidence before scale · no platform commitment
YANC · Solve Smarter. Scale Better.
Enjoyed this perspective?
Follow YANC on LinkedIn for new insights on business, technology and scale.