%20(1).png?width=2701&height=607&name=BRC_NEXA_LOGO_WHITE%20(2)%20(1).png "Cedar Rose"){kind=logo}
IN BRIEF for years, NEXA often advised clients to avoid complex custom software unless the business case was overwhelming. The reason was simple: software projects were slow, expensive, fragile and often too dependent on a few individuals. AI has changed that equation. Delivery is faster, iteration is cheaper, bug fixing is quicker and internal systems that once lived in spreadsheets can now become real operational assets and defensible IP.
There was a time when we regularly tried to talk clients out of building software. Not because software was unimportant, but because the economics and delivery risk often did not make sense for mid-sized businesses. A new internal platform or bespoke business system could sound strategic in a boardroom, then become painful in practice. Timelines drifted. Scope changed. Costs expanded. Knowledge sat with too few people. If the wrong stakeholder left the business halfway through, the project could lose momentum or collapse entirely.
That caution was justified. In many cases, the better advice was to improve process discipline first, simplify operations and avoid signing up for a large build that the business was not ready to absorb.
Today, our view is materially different.
At NEXA AI Lab, we now actively encourage companies to reconsider platform and system development. Not blindly and not because AI makes everything easy, but because the delivery environment has changed. The cost of iteration has fallen. The time to prototype has compressed. Bug fixing is faster. Documentation can be produced in parallel. Feature revisions no longer need to trigger the same level of delay and expense they once did. In practical terms, many of the reasons companies used to avoid software development have become far more manageable.
Why were custom software projects historically such a difficult bet for mid-sized businesses?
Historically, custom software projects were difficult because they asked businesses to absorb multiple forms of risk at the same time: technical risk, budget risk, organisational risk and dependency risk.
For a mid-sized company, this was rarely just a technology decision. It was a management decision, a cash-flow decision and often a political decision inside the organisation. The business needed clear requirements, committed stakeholders, patient leadership, reliable delivery partners, disciplined change control and enough internal stability to see the project through.
That is a lot to ask from any business. It is even more difficult when the process being digitised is already messy, undocumented, or heavily reliant on a few experienced individuals.
What were the most common reasons software development went wrong?
Most software projects did not fail because the idea was bad. They failed because complexity outpaced control. Once that happened, delays and budget pressure followed quickly.
The most common challenges included:
Requirements drift: teams started with one problem statement, then kept adding exceptions, edge cases and new requests once development began. Slow delivery cycles: every revision required more developer time, more QA time and more coordination overhead. Budget expansion: small changes often had disproportionate cost implications once architecture had been set. Stakeholder dependency: if the person who understood the workflow best left the company, the project lost context quickly. Developer dependency: too much logic lived in the heads of the build team rather than in living documentation. Spreadsheet entrenchment: the more manual workarounds a business had layered into Excel over time, the harder it became to translate that reality into clean product logic. Low visibility during delivery: leadership often did not know whether a project was genuinely on track or merely consuming time. Weak adoption after launch: a system could technically go live and still fail commercially if teams did not trust it or change behaviour.
In short, software projects used to demand too much patience and too much certainty at the same time. That combination pushed many sensible businesses to delay, defer, or abandon the idea altogether.
What has AI changed in the software delivery process?
AI has changed the speed and cost of iteration. That is the single biggest shift. Businesses no longer have to treat every new feature, bug, or workflow change as a heavy engineering event.
AI-assisted development does not replace software architecture, product thinking, or governance. Those still matter. What it does change is the amount of friction involved in turning ideas into working outputs. Teams can prototype faster, generate scaffolding faster, test options faster and resolve issues faster. Documentation can be drafted in parallel. User stories can be refined more quickly. Edge cases can be explored earlier. That compression matters.
Old software delivery reality / AI-assisted delivery reality / Commercial implication
Slow prototyping / Rapid prototyping and interface mock-up generation / Faster validation before major budget is committed Expensive revisions / Cheaper and quicker iteration cycles / Lower cost of learning and adjustment Manual bug-fixing bottlenecks / Faster debugging support and code review assistance / Reduced downtime and faster release cadence Heavy documentation lag / Documentation generated alongside delivery / Less key-person fragility Long gaps between business feedback and product change / Tighter feedback loops / Better product-market and process-fit
That does not mean every build should start tomorrow. It means the threshold for saying yes has changed. The historical risk premium around bespoke system development is no longer what it was.
Why has this changed NEXA's mindset?
It has changed our mindset because the balance between effort, risk and long-term value has improved. What once felt like an overcommitment now often looks like a sensible strategic investment.
For years, we saw many businesses trying to force increasingly complex operations through spreadsheets, inboxes, shared drives and manual approvals. That was understandable. Software felt too heavy. Today, in many cases, keeping those processes manual is the greater risk. The business becomes dependent on tribal knowledge, inconsistent file versions and key staff who know how the system really works because the system only exists inside their heads.
When AI lowers build friction, companies gain the option to formalise those processes sooner. They can move from operational improvisation to operational design.
Why should companies now think seriously about replacing complex Excel sheets and manual workflows?
Companies should think seriously about replacing complex spreadsheets because spreadsheets are often performing system-level jobs without system-level control. That becomes dangerous as the business grows.
Excel is useful. It is flexible. It is familiar. But many companies eventually stretch it far beyond its natural role. One spreadsheet becomes five. Logic gets embedded in formulas only one person understands. Data quality becomes uneven. Reporting becomes slow. Version control becomes unreliable. Auditability weakens. Decision-making suffers because the team spends too much time interpreting the mechanics of the file instead of acting on the insight.
A well-built internal platform does more than digitise the same mess. It creates structure. It standardises inputs. It makes approval paths visible. It stores information properly. It lets leadership see what is happening without waiting for manual compilation. It also removes the quiet operational anxiety that comes from knowing critical processes are one broken formula away from confusion.
What is the strategic value of turning internal process into software?
The strategic value is not just efficiency. It is ownership. Once a company captures its operating logic in software, it stops relying on fragmented memory and starts building an asset.
That asset can include workflow rules, approval logic, data structures, performance history, operational dashboards, customer-facing outputs, compliance trails and reporting views that are specific to how the business actually works. This is where platform development becomes more than an IT line item. It becomes business infrastructure.
For many mid-sized companies, this is one of the most overlooked forms of modern value creation. They already have the process knowledge. They already have the edge cases. They already have the know-how. What they have not done is convert that know-how into owned digital capability.
Why does that matter so much from an IP perspective?
It matters because intellectual property is not limited to patents or published inventions. In many businesses, the most commercially useful IP is embedded in how the company operates, how it serves customers, how it prices, how it evaluates data and how it makes decisions at scale.
When those mechanisms live inside scattered spreadsheets and human routines, they are difficult to protect, difficult to transfer and difficult to scale. When they are built into a system, they become more durable. They can be improved, licensed internally across divisions, rolled out across markets and in some cases turned into customer-facing products or services.
This is particularly important in sectors where the company's advantage comes from proprietary process, specialist workflow design, or unique insight generation. If the business can convert that into a platform, it moves from merely having experience to having codified advantage.
How does platform development improve data quality and decision-making?
Platform development improves decision-making because it gives businesses cleaner data, better continuity and more consistent visibility into what is happening. Good software reduces interpretation noise.
Once a workflow becomes systemised, data can be captured at the right point, stored in a structured way and analysed across time. That means management is no longer dependent on manually assembled reports or inconsistent snapshots. Instead, they can see trends, exceptions, bottlenecks and performance signals in a more reliable way.
This becomes even more valuable when the platform sits close to customer activity. If a company can connect operational process to customer-facing insight, it creates a stronger feedback loop. Patterns become easier to spot. Sales conversations improve. Support becomes more informed. Product decisions become more grounded. In some cases, the insight layer itself becomes a competitive differentiator.
Can internal platform development also create external USP?
Yes. In many cases, the strongest external differentiation starts with internal system design. If a business sees faster, acts faster and serves with more consistency, customers feel that difference.
Some companies will stop at internal efficiency. Others will discover that the same platform logic can power client portals, dashboards, service layers, reporting products, or insight-led experiences. That is where the move becomes more strategic. Internal software stops being back-office plumbing and starts becoming part of the customer proposition.
This is one reason we believe more companies should now be thinking about platforms rather than isolated tools. A platform creates the possibility of compounding value. One improvement in data structure or workflow design can support operations, reporting, leadership visibility and customer experience at the same time.
What risks still remain, even in the AI era?
AI has reduced delivery friction, but it has not removed the need for discipline. Companies can still build the wrong thing, build too much, or build without clear ownership.
The risks that still need active management include:
- Unclear problem definition: faster delivery is not useful if the business has not defined the real problem properly.
- Poor process design: software should not merely memorialise a bad workflow.
- Weak governance: permissions, approvals, data access and auditability still matter.
- Integration blind spots: platform value increases when systems connect properly to CRM, finance, ops and reporting tools.
- Adoption failure: if users do not trust or use the system, technical progress does not become commercial value.
So the message is not that software development is now risk-free. The message is that many of the old barriers are less severe and the upside is greater if companies approach platform development with the right structure.
How should a mid-sized business decide whether to build now?
A mid-sized business should consider building when the process is repeated often, costly to manage manually, important to the customer experience and strategically valuable enough to own.
A useful filter is simple:
Is this process currently too dependent on spreadsheets, inboxes, or a small number of individuals? Does the process affect speed, quality, compliance, or visibility? Would structured data from this process improve leadership decision-making? Could owning this workflow become a form of operational IP? Might this capability later support a customer-facing product or differentiated service?
If the answer to several of those questions is yes, the business should at least explore the build seriously.
Why this matters now
In a more cost-conscious market, companies need more than efficiency savings. They need assets that make them stronger, leaner and harder to replicate. Thoughtful platform development can do that.
This is part of a wider shift we see across the market. Businesses are moving away from labour-heavy ways of operating and towards systems that preserve knowledge, reduce dependence on manual work and create compounding value over time. That does not mean buying software indiscriminately. It means becoming much more intentional about what should be owned.
At NEXA, that is why our view has changed. We used to steer many clients away from new software projects because the downside often outweighed the upside. With AI-assisted development, that equation is different. For the right business problem, at the right time, with the right scope, platform development is no longer something to avoid. It is something to consider seriously.
Final thought: from operational workaround to owned business asset
The real opportunity is not simply to build software faster. It is to convert messy internal complexity into clean, owned capability. That is where the lasting value sits.
For companies still running critical operations through complex Excel files, manual approvals and fragmented reporting, the question is no longer whether software sounds ambitious. The better question is whether continuing without it is now the greater risk.
Frequently asked questions
-
Why were mid-sized businesses often advised against complex software projects? Historically, many software projects carried high delivery risk. Timelines slipped, budgets expanded, scope changed and too much knowledge often sat with a small group of internal stakeholders or external developers.
-
What has AI changed in platform development? AI has accelerated prototyping, coding support, debugging, documentation, testing and revision cycles. That does not remove the need for product thinking or governance, but it does reduce the cost and time of iteration significantly.
-
Why does internal platform development create IP? A well-built internal platform captures a company's process logic, decision rules, workflow structure, data history and operating know-how. That becomes proprietary capability the business owns rather than scattered knowledge held in spreadsheets and inboxes.
-
Should every company build software now? No. Companies should build only when the process is important, repeated, hard to manage manually and valuable enough to justify ownership. AI has improved the economics, but good platform decisions still require commercial discipline.
