I build what companies still do by hand.

I studied Computer Science with a specialisation in Data Science at MVJ College of Engineering in Bengaluru, graduating in 2024. Data science taught me to look at problems through the data behind them, but the part I enjoyed most was always what happened after the analysis: turning an insight into something that runs on its own.

My first professional role was as a Data Analyst Consultant at Spire Technologies. I built Python and SQL pipelines that processed more than 100,000 records with better data quality, created Power BI dashboards for recruitment analytics that cut reporting turnaround by 15%, and optimised MongoDB workflows with Python and AWS. It was my first taste of how much time an organisation spends moving data around by hand.

In July 2025 I joined Envision Beyond as a Business Analyst Trainee. The team had no data pipelines yet, so I wrote the first ETL scripts for extraction, clean-up and scheduled refreshes, automated recurring reports and manual data entry with Python, and built the early dashboards that later became the reporting layer for the AI automation work. Three months later I was promoted straight to Business Analyst, skipping a level.

Since then my work has been about replacing manual workflows with systems. I led the multi-tenant e-Invoicing platform that now processes more than 2,000 financial documents a month for Malaysian LHDN compliance. I built an email lead agent that handles more than 100 inbound emails a day, categorizing, researching, drafting and assigning each lead by region and seniority, with PostgreSQL synced to Odoo. I built the company's enterprise website, which scores 100 for performance and ranks well, and the content engine that runs on it, which brought in qualified inbound leads within 30 days and first-page rankings within two months. Alongside that I built Aria, a real-time voice assistant, and migrated legacy UiPath workflows to IBM RPA.

A lot of what is sold as AI today is a chatbot with a language model behind it. That can be useful, but it is rarely what changes how a business runs. The systems that do are pipelines, and the model is only one step inside them.

A real AI system starts with data ingestion: pulling emails, documents and records from the places they already arrive. It categorizes what comes in, deciding what each item is and what should happen to it. It extracts and validates, turning messy input into structured data and refusing anything that does not pass the rules. It routes and assigns, sending each item to the right person or system, for example leads by region and seniority. And it integrates and records, writing results into PostgreSQL, Odoo or Outlook and keeping an audit trail of every step.

The language model does the parts that need language: reading an email, drafting a reply, summarising a company, writing an article. Everything around it is engineering, and that engineering decides whether the system can be trusted with 100 emails a day or 2,000 documents a month.

I start by understanding the work, not the technology. That means talking to the people who do the job today, watching where the data comes from and where it goes, and writing down what they check and where things go wrong. It is the least glamorous part of any project and the one that decides whether the result gets used.

Then I build in small, working pieces. The first version handles one well-defined flow end to end, in production, with real data. It is measured against numbers that matter to the business, such as time to reply, documents processed, rejections or hours saved, before anything is widened.

I explain what I build in plain language. The people who own a process should understand what the system does, where a person still decides, and what happens when something fails. Every system I ship keeps a record of what it did, so nobody has to take its behaviour on trust.

I also care about handover. A system should not depend on me to keep running. That means clear configuration instead of hard-coded rules, logs that explain what happened, and documentation that the next person can follow. The e-Invoicing platform, for example, is set up so that adding a new tenant is a configuration task rather than a development project.

And I stay close to outcomes. A pipeline that runs but that nobody relies on is not finished. I would rather ship something modest that a team uses every day than something impressive that sits unused. Usefulness is the only benchmark I trust.