Businesses often overestimate what technology can achieve in the short term,
and underestimate what it delivers over the long term.
Technology evolves rapidly.
Human behaviour adapts slowly.
Real transformation happens when the two align.
The internet is a good example.
It didn’t change everything overnight - but over time, it reshaped how we work, communicate, and build businesses.
AI won’t change everything overnight - but it may leave very little unchanged.
Notes
Short notes.
I don’t know how things work in Silicon Valley - I’ve never been to any place west of London.
But here in India, across acres of the software support and systems maintenance ecosystem - call it IT services, outsourcing, offshoring, or GCCs - the most respected people are the ones who can debug.
Not the ones who write the most code.
The ones who can fix what breaks.
These are professionals who have seen so many systems fail, behave strangely, and recover that they’ve internalised how technology really works. Give them a problem and, within minutes, they can trace the root cause and suggest a fix.
Early in my career, I worked with one such professional.
The probability of finding him at the sutta-tapri outside the office was often higher than finding him at his desk. But when something broke, someone would walk up to him, explain the issue, and he would calmly point to the exact place in the system where things had gone wrong.
And, he was almost always right.
That’s the beauty of real technology expertise - people who have seen systems behave in the messy complexity of real-world environments.
Will AI replace such experts?
Maybe. Maybe not.
But will AI create the need for many more such experts?
I would say - yes.
Someone will still have to debug the future.
Every factory visit teaches me something new. Every warehouse reveals something most reports don't.
I've had the opportunity of spending time on shop floors and navigating through pallet racking across many facilities - and what strikes me, every single time, is how much a physical space reveals about the health of a business.
The layout of a warehouse. The rhythm of a production line. The way material moves - or doesn't.
You notice things that never make it into dashboards or MIS reports. Where bottlenecks quietly form. Where workarounds have become routine. Where a small process fix could unlock something much larger downstream.
These aren't just operational details. They are the story of how efficiently a business truly runs - told not in numbers, but in motion, space, and the behaviour of people doing real work.
And that story is almost always more honest than any presentation in a boardroom.
For anyone serious about manufacturing or supply chain - or about building systems that actually serve these environments - there is no substitute for time spent on the ground.
Observe first. Then design.
The AI conversation in tech feels increasingly polarised.
One camp believes AI is the end game - that software engineers, analysts, designers, maybe even founders, will soon be optional.
The other camp dismisses it - citing non-determinism, hallucinations, and the lack of long-term proof.
Both positions, in my view, are intellectually lazy.
AI is neither apocalypse nor illusion.
It is a tool - a powerful one. It accelerates some tasks dramatically. It performs brilliantly in narrow contexts. It is unreliable in others. And like every tool before it, it will evolve.
History offers perspective.
When Canva emerged, it didn’t eliminate designers - it expanded the design market. When Figma accelerated collaboration, it didn’t reduce opportunity - it increased the velocity of product creation.
Tools reduce friction.
Reduced friction expands ambition.
AI will likely democratise information processing and lower the barrier to building. But building systems is not the same as generating outputs.
Architecture. Accountability. Trade-offs. Long-term consequences. Context.
These are not prompt-level decisions.
The real question isn’t “Will AI replace us?”
It’s “What becomes more valuable when execution gets cheaper?”
That’s where the real debate should be.
Once the hype around AI settles and the true cost of using AI tools is fully understood, an interesting question emerges:
What does the steady-state impact of AI look like - especially for the technology industry?
I’ve been thinking about this for a while, and the most compelling lens I’ve found is an analogy with industrialisation.
Industrialisation dramatically reduced the cost of production, while the cost of human effort steadily increased. Over time, replacing a product became cheaper than fixing it. Cars, phones, laptops - almost everything today is designed with a short lifecycle. Manufacturers actively phase out legacy versions within 3-5 years, making repair or long-term maintenance economically irrational.
Product lifecycles that once spanned 15-20 years are now closer to 3-5.
This raises an uncomfortable but important question for software:
Will AI make rebuilding software cheaper than fixing or upgrading existing systems?
If that turns out to be the trajectory, the implications are profound. Software systems may become increasingly disposable - rewritten rather than refactored, replaced rather than evolved.
In such a world, the most critical architectural layer will not be the application, the UI or even the business logic.
It will be the data.
Think about how businesses once maintained physical ledgers. The format was simple, durable and readable by any qualified professional, regardless of who created it.
In the future, data will serve the same role - the only enduring business context.
Everything else may be transient.
Businesses often overestimate what technology can achieve in the short term,
and underestimate what it delivers over the long term.
Technology evolves rapidly.
Human behaviour adapts slowly.
Real transformation happens when the two align.
The internet is a good example.
It didn’t change everything overnight - but over time, it reshaped how we work, communicate, and build businesses.
AI won’t change everything overnight - but it may leave very little unchanged.
Technology is often born out of necessity - to solve a problem at hand.
But it rarely stops there.
Once a problem is solved, the human instinct is to push the same solution toward a bigger frontier. When vehicles enabled faster movement from point A to point B, the saved time wasn’t banked - it was used to travel farther, explore more, and reach what was previously inaccessible.
The same principle applies to process automation and ERP systems.
Businesses typically initiate automation when something isn’t working. But when the system succeeds, expectations evolve. Leaders naturally want to extract more value, scale further, and do more with the same platform.
The challenge arises when the system was not planned or engineered for that next phase of growth.
This is where the role of consultants becomes critical. Those who work closely with business decision-makers, anticipate future needs, and align systems with long-term intent significantly enhance the return on investment from ERP and process automation initiatives.
Technology solves problems.
Good engineering - powered by good consulting - enables growth.
Software systems are rarely viewed as 𝘦𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘪𝘯𝘨 systems - largely because the process behind them is invisible.
Unlike a building or a vehicle, where even non-engineers can see how things are constructed, software reveals only the final interface. The architecture beneath it - code quality, optimisation, energy efficiency - remains unseen and often unconsidered.
Yet, it is precisely this engineering layer that determines the true total cost of ownership.
As businesses mature in their technology choices, this perspective is changing - and those who prioritise engineering today are quietly building more resilient, scalable systems for tomorrow.
Approach to building an MVP is fundamentally different from building a mature product, and very few teams can successfully navigate this transition. Let me explain why.
An MVP exists to validate the core workflow - the central problem the startup or business aims to solve. The operative word here is IF.
An MVP is designed to check if the technology can solve the intended business problem. It must prove the happy flow, deliver the core value proposition, and demonstrate product-market fit. If it does that, the MVP is considered a success.
But the moment the MVP must evolve into a mature system, everything changes.
The focus shifts from core functionality to edge cases.
From scenarios where the system should work to scenarios where the system could break.
This requires deep analysis of every possible path a user may take, mapping the universe of scenarios, designing the corresponding workflows, and validating them through rigorous testing.
Beyond logic and workflows, a mature product must also deliver on interface quality, user experience, performance engineering, and long-term scalability.
The transition, therefore, is not a linear upgrade. It is a shift from proving possibility to engineering reliability.
Teams that succeed in this transition understand that MVP building is an experiment, but product maturity is an operating discipline. The competitive advantage belongs to those who can evolve from rapid validation to deliberate, scalable engineering without losing speed or control.