Q1. Could you start by giving us a brief overview of your professional background, particularly focusing on your expertise in the industry?

I have overall about 32 years of experience in the IT industry. After graduating from IT-BHU in Computer Science in 1994, I worked with multiple global IT giants like TCS, Infosys, Keane, and HCL Technologies for the first 18–19 years of my career.

During my initial years, I worked across various domains and was responsible for software engineering roles up to tech manager level, building products in healthcare and fintech, which were my primary focus areas in the beginning.

From 2012 onwards, I shifted towards product engineering and took over complete technology strategy and end-to-end product engineering roles. That journey started when I launched my own startup, Impulsar Infotech, in 2013.

After that, I joined Comviva, which is a fintech-specialized multinational global SaaS company, where I was heading engineering and technology. Later, I joined RateGain, a global travel SaaS company, where again I was leading end-to-end technology strategy and product engineering.

For the last four years, I’ve been with Solv, which is a Standard Chartered-backed research and technology company under SC Ventures. I joined at the inception stage in October 2021, when the company was operating at a very low revenue base, and we scaled it into almost a $500 million company in about four years.

We built the whole product from scratch, which was a B2B marketplace embedded with fintech capabilities. It was a combined tech model that scaled from practically zero to around $400–500 million in four years.

Currently, I’m more involved in advisory roles, academics, startup mentoring, and working with a couple of startups at the board level, helping drive technology strategy from the very inception stage.

 

Q2. As open networks rapidly scale their B2B transaction protocols across the Indian market, how can a proprietary digital commerce or marketplace platform design its technology to avoid becoming a commoditized conduit?

This was actually one of the first aspects that came to my mind when I joined Solv in October 2021. At that time, ONDC — Open Network for Digital Commerce — was just coming into the picture. India was beginning to capitalize on it, primarily for B2C, although B2B was also becoming relevant.

The same challenge we faced was ensuring that when we built a marketplace platform, it could not remain a generic platform. We had to make sure it became a leader in that space.

If you look at how open networks operate, they are primarily focused on connecting buyers and sellers. Orders get placed, shipped from one location to another, pricing happens, and products are listed in catalogs. Everybody can access that information, which means the data security aspect is not very strong.

There were several things missing from that model. For example, if I’m looking at intercity delivery, how do I build a platform that can handle the complexities of logistics? I’m not just looking at a buyer placing an order and a seller fulfilling it. I’m looking at how the complete infrastructure around the transaction is built.

From the moment a listing is placed on the platform to the moment a buyer places an order, and eventually the delivery through multiple optimized routes, the platform should intelligently manage logistics hubs, optimize deliveries, and secure data in a much more structured environment.

Another important aspect is intelligence. Open networks don’t provide database intelligence. For example, how do I determine a buyer’s score, a seller’s score, or a logistics provider’s score? I need to build engines that decide which logistics provider should be preferred for the fastest delivery at the lowest cost.

Those kinds of algorithms are data-dependent, and that’s where the AI aspect comes in. You build a big data environment and then use that intelligence layer to make the platform differentiated.

The fintech integration was another major differentiator. We looked at providing credit to buyers through mechanisms like Buy Now Pay Later. Then the challenge becomes: how do I determine whether the buyer qualifies for credit? Do I have a credit-scoring mechanism built into my platform?

We built those capabilities to work dynamically and in real time. We also built supply chain financing capabilities where the platform funds large distributors and manages repayment through a complete loan management system integrated into the marketplace itself.

So the same platform was handling both digital commerce and fintech integration, which made it unique.

When you build in this manner, you naturally avoid becoming commoditized because you are no longer just building a marketplace. You are building a complete infrastructure-based, AI-native, end-to-end ecosystem rather than a simple transaction-based solution.

You also create intelligent pricing models, personalized catalogs, seller scoring, and buyer-specific pricing engines. That level of intelligence and infrastructure is what differentiates the platform from becoming just another conduit.

 

Q3. From an enterprise integration standpoint, when deploying software into traditional, highly siloed corporate architectures, what design choices can elevate the platform?

This becomes very critical when working with large banks or enterprises that typically operate on legacy systems.

The first thing you notice is that these organizations usually maintain their own private data centers because they believe their data is more secure there and they are hesitant to move to public cloud infrastructure.

The first design choice, therefore, is making the system cloud-native while implementing a zero-trust architecture. Zero trust means ensuring infrastructure security, data security, and application security together. Every transaction goes through multiple validation checks, including multi-factor authentication.

The idea is to give enterprises confidence that deploying on public cloud infrastructure does not automatically expose them to security risks.

The second major aspect is making the system service-driven and microservices-based. The moment you decouple services from each other, the system becomes stateless. If one service fails, the entire system doesn’t collapse.

In legacy monolithic architectures, one failure can impact the entire application. Large organizations often try to reuse existing infrastructure and systems instead of rethinking the architecture completely, and that creates long-term scalability issues.

That’s why we approached the system as a completely standalone architecture — something that could scale independently, integrate easily with third-party systems, and become multi-tenant very quickly.

An event-driven architecture becomes critical here. Every transaction request gets logged into queues rather than directly interacting with databases. The database remains isolated behind the backend layer.

That layered architecture is extremely important. The frontend and middleware do not directly access the database. Instead, the backend layer handles all database operations.

So the ideal approach is an event-driven, cloud-native, layered architecture with microservices and decoupled systems. If you want the platform to scale 30x or 50x in the future, these architectural decisions must be made from the beginning because they become extremely difficult to change later.

 

Q4. When managing multi-party enterprise marketplaces, what operational safety buffers or automated reconciliation layers are required to prevent systemic data mismatches?

This is a very critical question, and I can explain it based on challenges we faced ourselves.

Typically, when a transaction completes, the buyer makes a payment, but that payment first goes into an escrow account. The seller should not receive immediate settlement because there could be several issues — discounts may not have been applied properly, deliveries may be incomplete, items may be missing, or the shipment may fail entirely.

You can have partial deliveries, failed deliveries, or return-to-origin scenarios. Therefore, the order management system has to be completely real-time and dynamic.

The first critical safety buffer is complete order visibility. At any given time, you should know exactly where the order is — whether it is in transit, out for delivery, or delivered.

In a multi-party ecosystem, you are dealing with buyers, sellers, logistics providers, payment gateways, and ERP systems simultaneously. Every one of these systems is dynamically interacting with your platform.

The second important layer is reconciliation. We built a dedicated reconciliation platform beyond the marketplace itself.

The reconciliation layer takes transaction data from payment gateways, logistics systems, ERP systems, and third-party integrations and validates everything before settlement occurs.

Settlement only happens after all checks and balances are completed. Depending on the situation, settlement could be full settlement, partial settlement, or no settlement at all.

The reconciliation platform continuously validates delivery status, payment status, and third-party transaction records before releasing payments.

Many mismatches happen because third-party systems fail to update statuses correctly. For example, a product may have been delivered, but the logistics partner still shows the order as “in transit.” In that situation, your source of truth itself becomes incorrect.

That creates major financial and operational issues because revenue is recognized only after successful settlement. If reconciliation fails, it impacts financial reporting and P&L visibility as well.

That’s why every integration point requires validation layers, monitoring systems, interfaces with checks and balances, and a clearly defined standard operating procedure.

Even when you introduce agentic AI workflows, those agents must still be trained on these operational processes and governance layers. Whether the reconciliation is manual or automated, the process discipline remains extremely important.

 

Q5. When an enterprise platform scales its transactional and data volumes in the Indian market, what architectural designs should be considered to scale linearly with user growth?

The first and most important principle is to build a cloud-native, event-driven architecture. The key aspect of scalability is to avoid creating bottlenecks.

Every workflow should be broken into multiple independent events. For example, in an order lifecycle, stock validation, product selection, order placement, invoice generation, payment, fulfillment, and delivery should all operate as separate events.

If one event fails, the rest of the system should continue functioning normally without affecting other transactions.

That is why every request in the workflow should operate through message queues like Kafka or Pub/Sub models.

The architecture should consist of microservices stitched together into workflows. That creates scalability and fault isolation.

The next aspect is infrastructure scalability. You should deploy using containerized infrastructure orchestrated through Kubernetes, so the system can automatically scale up or down based on usage.

You don’t build infrastructure assuming a fixed number of users. Instead, you build infrastructure that can scale for an unknown number of users dynamically.

A serverless architecture can further improve scalability because you no longer worry about underlying hardware management. Every node becomes a service, and the infrastructure automatically scales based on demand.

At the same time, the database must remain completely decoupled. There should always be a separate data access layer.

The frontend queues requests into the event-driven system, the middleware processes those requests, and the backend data access layer handles database operations.

So the ideal model is a fully decoupled, multi-layer, cloud-native architecture with auto-scalable infrastructure and no architectural bottlenecks.

 

Q6. As enterprise software transitions toward Agentic AI workflows that independently trigger cross-application transactions, how can API permissions and state-machine layers be refactored to prevent runaway compute costs from recursive API loops?

This is one of the latest and most critical challenges emerging with agentic AI workflows.

Earlier, systems operated through predefined API-based designs where programs controlled a fixed set of API calls. But with agentic AI, the agents themselves can get stuck in loops.

An agent may repeatedly hit the same API trying to retrieve the correct answer because it cannot recognize that semantically similar queries are producing the same response.

Even a very small variation in query structure can cause the agent to repeatedly generate requests and tokens, which dramatically increases compute costs.

Previously, API gateways mainly controlled request rate limits. Now, with agentic AI, the challenge shifts toward token management.

You may technically have only one API call, but the number of tokens being generated behind that request can become extremely large.

This is where AI gateways and deterministic state machines become important.

A deterministic state machine acts like an agent monitoring another agent. It observes the LLM workflow and determines whether token generation has crossed acceptable limits. If it detects excessive token processing, it immediately stops the workflow and throws an error instead of allowing the loop to continue indefinitely.

Another important layer is semantic similarity detection. If the system determines that two queries are 98–99% similar, it should return the same cached response rather than repeatedly hitting APIs or databases.

Caching becomes very important here. Similar responses can be stored in cache with predefined TTLs — time-to-live durations — so that repeated queries reuse existing results instead of triggering fresh compute cycles.

At every stage of the workflow, you create trigger points with checks and balances. These guided workflows prevent agents from operating completely independently.

You are effectively building wrappers around the agentic workflow through deterministic state machines, semantic validation, cache management, and controlled trigger points.

This entire area is still evolving. As organizations deploy more agentic AI systems, they are learning these limitations in real time and continuously improving the governance layers around them.

 

Q7. If you were an investor looking at companies within the space, what critical question would you pose to their senior management?

If I were evaluating a B2B commerce marketplace company, one of my first questions would be: how will your architecture scale 30x in the next three years?

I would want a very clear understanding of their technology roadmap and the architectural decisions they have made to support that scale.

If the company has 100 users today, it could have 300,000 users in a few years. I would want to know whether their infrastructure and platform design can handle that growth.

My second critical question would be how they are differentiating themselves from becoming a commoditized marketplace.

What have they built in terms of logistics and supply chain infrastructure that allows buyers and sellers across the country to transact seamlessly, regardless of distance and operational complexity?

For example, if a buyer is in Kashmir and the seller is in Kanyakumari, what systems have they built to ensure efficient, risk-free fulfillment?

I would also evaluate how they manage financing and risk. If they provide credit to SMEs, how do they ensure real-time funding while controlling financial risk?

I would ask whether they have integrated with NBFCs or banks, how their funding model operates, and how they ensure smooth order-to-delivery execution without delays.

Another major aspect would be cataloging and pricing. In B2B commerce, packaging variability can significantly impact logistics costs and operational complexity.

I would want to know how rigorously they manage catalog accuracy, pricing intelligence, volumetric calculations, and logistics coordination.

Security would be another key area. Are they operating within a zero-trust environment? How are they handling customer data and personal identification data? Are they following modern security protocols?

I would also evaluate whether the platform is AI-native. Are they scoring buyers, sellers, and logistics providers? Are they using accumulated data to make their marketplace more intelligent over time?

The stage of the company also matters. For a seed-stage company, I would focus more on mindset and architectural thinking. For a Series A or Series B company, my questions would shift more toward evolution, maturity, AI adoption, and how effectively they are leveraging the data they have accumulated over the years.