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.
All entries
Latest notes and writing.
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.
The economics of building a business have fundamentally changed.
What was once sales-led and execution-driven has now become marketing-led and perception-driven. This shift has significantly increased the cost of entry and the cost of scale.
Historically, starting a business was relatively simple. You created or sourced a product and deployed sales. The primary investment was in inventory, relationships, and field execution. Sales generated immediate feedback loops, cash flow, and market validation.
Today, businesses are required to invest heavily even before their first meaningful revenue milestone. Brand positioning, narrative control, visibility, digital distribution, and sustained marketing infrastructure have become baseline requirements, not differentiators.
In practical terms, what was earlier a cost of selling has now evolved into a cost of being considered.
Selling must now appear non-transactional. It must signal aspiration, relevance, and market credibility. This has layered additional complexity and capital intensity into the operating model of modern businesses.
For CXOs and investors, this has direct implications:
Return on capital is now influenced as much by perception architecture as by operational efficiency. GTM strategy today carries a structural cost that did not exist a decade ago.
The critical question is no longer whether a business can sell.
It is whether the business model can sustain the rising cost of attention, relevance, and narrative without eroding long-term profitability.
In this environment, strategic advantage will belong to organisations that can balance perception with performance, and growth with discipline.
Where is your pseudo-code?
Let’s be honest: the probability of meeting a real software engineer today is about as low as the probability of a start-up actually succeeding.
Most people writing code are not Engineers.
They’re stack or platform loyalists.
“I’m a Python developer.”
“I’m a MERN developer.”
“I do Power BI.”
“I’m a Salesforce person.”
That’s fine - but let’s call it what it is: you’re a developer, not an Engineer.
And here’s the uncomfortable truth:
You can’t build meaningful software solutions by thinking like a developer.
Developers jump into code.
Engineers ask questions.
Engineers:
• think in first principles
• understand the business case better than the business team
• break messy problems into crisp, logical systems
• and only then create something worth coding
Developers chase syntax.
Engineers chase clarity.
Developers start with the code editor.
Engineers start with the pseudo-code.
That’s why I always gravitate towards techies who think like Engineers - the ones who refuse to write a single line of code until the logic is bulletproof.
The ones who start with the only question that separates a developer from an Engineer:
Where is your pseudo-code?
Cognitive hypocrisy is when people recognize the gap between their stated beliefs and their actual actions, creating internal discomfort similar to cognitive dissonance - but focused on their own inconsistencies.
A classic example in today’s world:
Tech leaders who fully understand the limitations of AI... but still oversell it because clients or management want to believe it’s a magic pill.
I’ve seen so many “we’re shutting down” posts from founders in India that they barely sting anymore. It almost feels inevitable - because that’s the narrative start-up media has amplified: only x% survive beyond y years.
But statistics alone don’t explain why. They’re just numbers, not causes.
If we take a hard look at India’s “tech” start-up investments over the past two decades, one truth emerges: we’ve invested heavily in building products, but very little in distribution, and almost nothing in internal processes and systems. And that is where the cracks appear.
Start-ups build good ideas, great products, but distribution is left to costly, inefficient online pushes. Many never scale. Among the few that do, too many collapse because they lack the processes and systems to sustain growth.
We’ve built castles, but they’re in the air. The foundations remain weak.
The time is now:
To build distribution.
To define processes.
To trust systems.
And here’s the truth that will make some engineers uncomfortable: Tech in India doesn’t just need better builders. It needs better sellers. And the first batch of sellers must come from among the engineers themselves - because they understand the technology, and they must learn to understand the business.
That’s how Engineer’s Day stops being symbolic - and starts being significant.