Profitability Is Becoming an Architecture Question

We often celebrate a technology business when its revenue grows. I am more interested in what happens to its costs when the next million customers arrive.

Does the platform become more efficient? Or does every additional transaction bring another layer of cloud expenditure, operational complexity and manual intervention?

That distinction separates growth supported by technology from growth merely accompanied by it.

An Inc42 analysis of Q2 FY27 describes improving profitability across India’s listed fintech, logistics and ecommerce businesses, despite softer consumer demand. Its central signal is that EBITDA grew faster than revenue across the nine profitable companies it examined, although earnings remained concentrated and regulatory uncertainties persisted.

For enterprise leaders, this raises a question beyond quarterly performance: is the architecture creating operating leverage-or quietly consuming it?

Scale Is Not the Same as Leverage

A platform can process twice as many transactions without becoming a better business.

If infrastructure costs, exception-handling teams and customer acquisition expenses rise proportionately, scale has increased. Operating leverage has not.

I believe architects should treat unit economics as a design constraint, alongside security, availability and latency.

That means measuring cost per successful business outcome-not simply cost per API call.

In logistics, the relevant outcome might be a successfully delivered shipment after accounting for failed attempts and returns. In fintech, it might be a completed, reconciled transaction with fraud and support costs included.

Technical efficiency matters. But optimising an inexpensive API while ignoring an expensive reconciliation workflow is precision applied to the wrong problem.

Automation Must Survive the Exceptions

Route optimisation, warehouse automation and AI-assisted operations offer credible paths to better margins. But deploying technology is not the same as capturing its economic value.

The difficult work sits in the exceptions: incomplete addresses, disputed payments, unreliable connectivity and demand spikes.

An AI system that performs impressively under normal conditions may still create costly escalation queues when conditions change.

My architectural preference is straightforward: automate repeatable decisions, define confidence thresholds, preserve human escalation and instrument the complete workflow.

For generative AI, this also means accounting for inference costs, evaluation, privacy controls and incorrect outputs. A cheaper interaction is not a saving if it produces an expensive mistake.

The useful metric is the cost of a correctly completed outcome, not the number of tasks automated.

Regulation Belongs in the Design

Fintech’s monetisation opportunities also expose a structural risk: economics built around rules that can change.

Any proposed payment fee should remain a scenario, not an assumed revenue stream.

Enterprises need configurable pricing, auditable policy enforcement and clear separation between transaction processing and commercial rules. This does not require turning every function into a microservice. It requires boundaries that allow regulatory change without destabilising the platform.

Diversification deserves similar discipline. Selling more services to existing customers can improve economics-but it can also produce tangled dependencies, excessive data access and growing compliance exposure.

Reuse capabilities. Do not casually reuse permissions.

The Northeast Tests the Assumptions

For businesses serving Northeast India, these questions become particularly concrete.

Terrain, dispersed demand and intermittent connectivity can expose assumptions hidden by metropolitan scale. A routing model optimised for dense urban deliveries may not transfer cleanly to a remote district.

Offline-capable workflows, asynchronous synchronisation and locally informed exception handling are therefore not peripheral features. They can determine whether a service is economically viable.

National scale should accommodate local operating realities, not erase them.

What Leaders Should Ask Next

• Measure unit economics end to end, including failures, returns and manual intervention.
• Test peak-load economics, not just peak-load performance.
• Demand evidence of automation’s value, including quality and recovery costs.
• Design for policy change, without overengineering speculative requirements.

Quarterly profits are encouraging. They are not proof of architectural excellence.

The stronger test is whether a business can serve its next customer reliably, responsibly and at a sustainably lower incremental cost.

---

About the Author: Sanjeev Sarma is the Founder Director and Chief Software Architect at Webx Technologies. With a core focus on Generative AI integration, Cloud-Native Scalability, and Enterprise Software Architecture, he has spent over two decades driving digital transformation across Northeast India and beyond. Beyond his corporate leadership, Sanjeev is deeply invested in shaping the future of the IT industry. He serves as an Industry Expert on the Board of Studies for Assam Don Bosco University’s School of Technology, advises state technology committees, and actively mentors emerging tech startups at STPI. He brings a unique, dual perspective of high-level enterprise execution and future-ready academic curriculum development.