Following the source behind a plausible result

I grew up in Surat in a Parsi family that valued repairing something well enough for the next person to use it. My interest in electronics led me to Savrenil Institute of Engineering, where I completed a Bachelor of Engineering in May 1995. I joined Kelmora Imaging Works in July, working on equipment and software that converted paper documents into digital images. A scanned page could look acceptable at first glance while missing a faint mark or an edge that mattered to the person reading it. That experience made the source of a digital result part of my engineering curiosity.

The early job combined testing, fault investigation and visits to customers using the equipment. I worked with mechanical and software colleagues because the cause of an unreadable image did not always sit neatly inside one discipline. A feed problem, a calibration setting and an interpretation rule could produce similar symptoms. I learnt to preserve the example and reproduce the conditions before proposing a repair. I also learnt that a demonstration chosen by the supplier can hide the documents the customer actually struggles with. Ordinary use was less tidy than the test pack on our desk.

In February 2001 I joined Orevathi Settlement Systems as an integration engineer. The company supplied software that helped financial institutions compare records and manage exceptions. It did not move money itself. My job was to connect incoming files with the product's representation of the work, which required careful attention to what each field meant. A reference might be unique within one source but repeated across another period or institution. An amount could be identical on two records without establishing that they described the same obligation. These were business distinctions with consequences for the engineering design.

I became product architect in September 2008. Instead of solving one institution's integration, I had to decide how the product should express differences across customers. We wanted reusable components, but reuse could be harmful if it hid a distinction that finance or operations needed to preserve. I worked with delivery colleagues to identify which requirements were genuinely shared and which required an explicit configuration or a separate review. The product could propose and organise evidence. It could not acquire a client's authority to settle a disputed position because an algorithm had found a convenient pairing.

The head of engineering appointment came in April 2015. I took responsibility for teams rather than only architecture and learnt how commercial commitments shape technical work before a project formally begins. A promised deadline or customer-specific feature could consume the capacity assumed in the rest of the roadmap. I wanted estimates to include the continuing support cost, not only the first implementation. I also developed engineering managers able to explain why a requirement needed clarification without turning every sales conversation into a refusal. The aim was an agreement the company could actually maintain.

In 2018 management bought 64% of Orevathi, with a private growth fund taking 36%. The company remained a specialist software supplier rather than becoming a financial intermediary. The ownership change increased the attention on repeatable product economics and the cost of exceptional commitments. I became CTO in July 2020, reporting to CEO Meher Dalsavi. I now lead 86 engineers through five heads and administer a ₹36 crore annual engineering budget. The company has 310 employees and 28 institutional clients, of which 24 are in India and four are across Nepal and Sri Lanka. FY 2026 revenue was ₹182 crore and profit before tax ₹21 crore.

The CTO role requires me to connect engineering decisions with the institution relying on our product. A matching result needs evidence of the underlying relationship. A shared worker pool needs a policy that explains how one customer's workload affects another. An export needs records that remain usable beyond our application. A sales commitment needs an implementation the company can support without quietly creating a separate product for every large account. These questions are technical, commercial and operational at the same time. I am responsible for the engineering judgement, while the CEO and other functions retain the decisions within their own remits.

I present product-engineering matters to the board but do not hold a directorship. The cases here retain a lower simulated automation rate, a slower large-client batch, an ₹18 lakh export repair and the cost of refusing a quick customer-specific branch. I have not made each decision look like an immediate saving. What connects them is a preference for software whose assumptions can be examined and whose commitments remain supportable after the initial sale. That is the experience I would bring to an external board, alongside the discipline of learning a different business and contributing through oversight rather than becoming another executive designer.

Open to Board appointments

Languages / English · Gujarati · Hindi