Build, Learn, Repeat: How Hackathons, Research Labs, and Production AI Changed the Way I Engineer

The visible part of an engineering journey is easy to list: a project shipped, an internship completed, a hackathon result announced. The useful part is harder to compress. It lives in the distance between the first idea and the version that finally worked: the measurement that disproved an assumption, the review that exposed a blind spot, and the decision to rebuild when polishing would have been more comfortable.

Looking back at my work across university, research labs, startups, financial services, and hackathons, I can see one loop repeating:

Build something small enough to test. Put it in front of reality. Learn where it fails. Build again with better judgment.

That loop has mattered more to me than any single framework. A parking problem became my first serious computer-vision system. Research work taught me to care about constraints and honest metrics. A sequence of hackathons changed how I scope, collaborate, and explain technical choices. Feedback from engineers and mentors began changing my code and the way I think.

This is not a formula for winning every time. It is the operating system I developed by repeatedly being wrong in useful ways.

Start with a problem that can answer back

One of my earliest substantial builds was a smart parking system. The problem was concrete: a campus can have parking space and still waste people’s time if nobody knows which slots are available.

The first useful version did not need a grand AI story. It needed to detect vehicles, map detections to actual parking regions, distinguish occupied slots from free ones, and keep working across a live video stream. I used YOLOv5 and PyTorch for vehicle detection, OpenCV for the video pipeline, and polygon-based regions to represent individual spaces. The system monitored more than 110 car and bike slots.

That project won the Smart Campus Hackathon, but the result was not its most durable contribution. It gave me my first clear experience of a model being only one component in a larger system. Detection accuracy meant little if the region mapping was brittle. A working notebook meant little if the frame-processing loop could not keep up. A technically correct output meant little if a user could not read availability quickly.

The project also changed how I choose scope. A useful prototype is not a miniature version of every feature you can imagine. It is the shortest path through the hardest uncertainty. For smart parking, that path ran from camera frame to vehicle detection to a correctly updated slot. Everything else could wait.

Research replaced impressive words with measurable questions

As I moved into research internships, the systems changed, but the loop stayed the same. The difference was that the feedback became less forgiving.

At Samsung R&D, I worked on an offers-retrieval system for e-commerce. Retrieval-Augmented Generation was interesting, but “using RAG” was not an outcome. The real questions were about memory, compute, retrieval quality, and whether the system could answer from changing product information without paying the cost of repeatedly fine-tuning a model. The work showed a reported 24× cost-efficiency improvement over that fine-tuning approach.

At Sony Research India, I worked on detecting surface defects in industrial imagery. The pipeline reached beyond model inference: images moved between an EC2-hosted endpoint, a FastAPI service, a Raspberry Pi, and persistent storage. Improving mean average precision from 56% to 78% mattered, but so did moving the result through the system reliably. It reinforced a lesson I had first seen in the parking project: a model metric and a usable system metric are related, but they are not the same thing.

My work at the Space Applications Centre, ISRO, made the evaluation problem even sharper. The task involved retrieving ocean-wind information from GNSS-R reflectometer data. Feature engineering and explainability techniques reduced the required parameters by more than 65%, while a stacked prediction approach improved the reported wind-retrieval error. The domain made careless claims impossible. A lower number is meaningful only when you can explain the data, baseline, units, and conditions behind it.

At Tata Steel, computer vision met another physical process: analysing the cross-section, rings, and ribs of TMT bars for quality assessment. The reported pipeline reduced error by 30% and improved efficiency by 45% compared with the existing manual intervention. Here again, the useful question was not “Which model is most advanced?” It was “Which approach makes this inspection more consistent, explainable, and practical?”

These environments trained a reflex I still rely on: translate an ambitious idea into a measurable question before choosing the technology. If I cannot state what should improve, for whom, and under which constraint, I am not ready to design the system.

Hackathons became compressed engineering laboratories

Hackathons introduced a different kind of reality. Research gives you room to investigate. A hackathon forces you to decide what deserves that room.

For the Standard Chartered hackathon, our team built FinSense, a loan-application system designed to replace lengthy form filling with a guided video interaction. That product idea immediately created several technical problems: speech transcription, Tamil-to-English translation, document identification, OCR, structured field extraction, conversational guidance, and rule-based eligibility decisions.

The OCR work is a good example of why a prototype still needs evaluation. We compared two document-processing paths. One used CRAFT to segment lines, TrOCR to recognise text, and a language model to map it into a shared JSON schema. Another used Florence-2-large for extraction before the same structuring step. On the project’s embedding-based evaluation, the reported scores were 95.71% and 98.36% respectively.

Those numbers did not end the decision. The second approach also required more memory. A hackathon system rarely has the luxury of treating accuracy, latency, compute, integration effort, and demo reliability as separate conversations. The job is to choose the trade-off that supports the product story and then make the whole path work.

FinSense placed third. The build also made me confront how easily a team can assemble several clever components without a clear spine. Our strongest product narrative was not “we used multiple models.” It was that a person could express a need naturally, provide documents, and move through a complex banking process with less friction, including in Tamil.

That lesson carried directly into Project Nova, our submission for GrabHack Campus Edition 2025. We built an equitable credit-scoring system for drivers and merchants in the Grab ecosystem. The repository contains a broader ML pipeline with multiple models, hyperparameter tuning, interpretability, bias analysis, dashboards, and role-specific views. But the core product question stayed simple: can credit assessment include people who may not fit conventional financial histories without turning the model into an unexplained score?

We progressed from more than 4,500 teams to the final ten and then finished second, earning ₹1 lakh and a pre-placement interview opportunity. It was my fifth hackathon win. I remember the result, but the more revealing part was the behaviour before it: another late night, another feature that felt essential, another round of polish, and the constant pressure to decide what would actually make the system clearer.

The win did not convince me that every late feature is worthwhile. It taught me almost the opposite. Under pressure, effort can disguise indecision. Strong teams keep asking which feature reduces the greatest uncertainty, which result the judges need to see, and what can be removed without weakening the argument.

Production work taught me the value of quiet execution

At Zocket, the loop moved into a startup environment. I worked on AI agents for marketing workflows, an insights dashboard, a budget-allocation strategist, and tools for analysing and moderating social comments. The pace was fast enough that ideas regularly met reality before they felt finished.

Receiving Zocket’s Tech Trailblazer Award was meaningful because it was not tied to one launch. In my public reflection, I described working “in the shadows”: supporting the team, shipping MVPs, breaking things, fixing them, and returning to the work. That is still the most accurate description of what I learned there.

The phrase “move fast” can sound like permission to be careless. In practice, moving fast in a real product means shortening the distance between a decision and trustworthy feedback. It means keeping a change small enough to understand, instrumenting what matters, and making recovery cheap. Speed without a feedback loop only helps a team reach the wrong conclusion sooner.

I also learned that consistency is an engineering skill. The visible breakthrough is often the accumulated result of ordinary actions: answering the unglamorous question, documenting the odd behaviour, testing the fallback, or staying with a problem after its novelty has disappeared.

Feedback changed from approval into a design tool

During my internship with BNY’s Wealth Services Engineering team, I worked on developer tools, RAG and agent-based assistance, UI modernisation, and build-pipeline improvements. The public outcomes include a reported 50% improvement to a monorepo build pipeline and a second-place finish in the Eliza Promptathon among more than 400 interns globally.

The deeper shift came from the review process. Mentors did not simply hand me answers. They asked questions that forced me to make the reasoning visible. Discussions about what worked, what failed, and what else we might try made each iteration more deliberate. Over eight weeks, feedback stopped feeling like a verdict delivered at the end. It became an input to the design.

That distinction mattered again at the BNY Service Design Jam during Shaastra at IIT Madras. Our team chose a client-service problem: identify potential SLA breaches early enough for a system to help people act before the breach occurs. We had to balance a broad, domain-independent agent architecture with specific user needs, prototype quickly, and compress the idea into a 60-second elevator pitch.

The team finished second. What stayed with me was how much the solution changed through questions from teammates, mentors, and judges. Each discussion revealed a different gap: the architecture was too broad, the user need was not sharp enough, or the explanation assumed knowledge the listener did not have.

Explaining a system is not decoration added after engineering. It is a test of the engineering. If I cannot describe why an agent should act, where a human should approve, what happens when a tool fails, and how success is observed, the design probably contains uncertainty I have not resolved.

The five principles I carry into the next build

Across these projects, the technologies changed from object detection and OCR to retrieval systems, agents, and developer tooling. Five principles remained stable.

1. Build the smallest path that can prove or disprove the idea

A prototype should test the riskiest assumption, not imitate the surface area of a finished product. Find the path from real input to useful output and make that path work first.

2. Measure honestly

Metrics need context: a baseline, a dataset, a definition, and a constraint. A better score is not automatically a better system, and a model improvement is not automatically a user improvement.

3. Invite feedback before the work feels safe

Early feedback is uncomfortable because it can invalidate work still in progress. That is exactly why it is valuable. The cheaper the current version is, the easier it is to change direction.

4. Treat explanation as part of implementation

Architecture diagrams, demos, documentation, and pitches expose gaps that code can hide. Clear explanation is not simplification for its own sake; it is evidence that the system has a coherent reason to exist.

5. Repeat without defending the first version

Iteration only works when the goal is a better outcome, not proof that the original idea was right. I want to keep the conviction to build and the humility to replace what I built.

“Build, learn, repeat” sounds simple. Living it is not. It asks for speed without carelessness, confidence without attachment, and ambition disciplined by measurement. I am still learning that balance. The next project will expose a new blind spot, and that is the point.

If you are working on AI systems where models, product decisions, and real constraints meet, I would enjoy comparing notes. Connect with me on LinkedIn or start a conversation by email.