I started writing Java. The problems got more interesting.
My degree was in Instrumentation and Control Engineering. After graduating in 2013 I joined Accenture in Bangalore writing Java web applications for insurance clients. I was good at it. The work was also completely disconnected from the kind of problems I actually wanted to work on.
In 2016 I left and founded Algoarts Technologies in Hyderabad. Agriculture and industrial automation. Problems that were real, physical, and completely unsolved by software alone. A farmer in a remote area does not have reliable electricity. A solar grinder in the field does not have a cloud connection. A valve manifold across a large farm cannot rely on someone with technical expertise to operate it.
Those constraints forced me to learn electronics and mechanical design by actually building products. You learn what a PCB layout decision does to your firmware timing when you are debugging a system in a field at noon with no laptop and a user who just needs it to work. You learn what a mechanical tolerance does to your motor driver when the thing fails after 200 operating cycles and you have to figure out why from 500 kilometres away.
The full-stack knowledge did not come from a plan. It came from the problems refusing to stay inside one discipline.
Seven products. Real environments. Numbers that came from the field.
Every product I have shipped had a constraint that could not be solved in one layer. The solar mill was a power electronics problem until it was a firmware problem until it was a mechanical load problem. The fall prevention device was a sensor fusion problem until it was a battery life problem until it was a manufacturing cost problem. The most important architecture decisions, the ones that saved a hardware spin or prevented a field failure or cut production costs by 40%, all happened at the boundary between disciplines.
That is what I am actually good at. Finding those boundaries, specifying how each layer couples to the others, and making sure the whole system stays coherent as individual layers evolve.
Across the portfolio, 19% average production cost reduction, 23% faster time to market, 7.8% efficiency improvement through ML integration in control systems. Those numbers came from designing systems where every layer is considered together.
Five inventions. Each one came from a constraint that the standard approach could not solve.
I do not file patents for portfolio reasons. Each of these came from a specific problem where existing approaches were wrong and the correct solution required something new. The valve system came from watching how water direction actually needed to work across large farms. The image-based docking system came from a precision alignment problem that mechanical tolerances alone could not close.
I built the framework and the tool because nothing existing worked for this kind of system.
Enterprise PLM systems are built for large organisations with separate teams per discipline and long development cycles. Pure agile frameworks are built for software that can be redeployed in minutes. Neither one handles the reality of a small team building hardware and software together, where a mechanical revision in week three can silently invalidate a firmware assumption that nobody has written down anywhere.
The Integrated Innovation Lifecycle (IIL) is a methodology I developed across ten years of building these systems. It combines agile iteration cycles inside structured stage gates. The iteration cycles are fast. Move, test, learn, adjust. The stage gates are real decision points. At each gate you check whether the mechanical layer, the electronics, the firmware and the software are still pointing at the same system. You find the misalignment there, before integration.
Mini-PLM operationalises IIL in software. It tracks versions across the full stack, links files to the decisions that produced them, and makes the coupling between layers visible. I built it because I kept losing track of which BOM revision corresponded to which schematic corresponded to which firmware branch. No existing tool tracked that coupling across layers. So I built one. It is open source and the demo is running a live build right now.
Both IIL and Mini-PLM are things I built for my own use that turned out to solve a problem other teams also have. That tends to be where the most useful tools come from.
I design the system. The specification is the deliverable.
After ten years of building across all four layers, I stopped wanting to do all four simultaneously. What I am actually most useful for is the architecture phase that happens before implementation begins. Or the diagnosis when an existing system keeps failing in ways the team cannot trace.
I work with teams who have a physical automation system they are building, or have built, and something is not right. Either it keeps failing at integration, a change in one layer keeps cascading into unexpected problems elsewhere, or they are starting a new system and want someone to specify how the layers connect before anyone starts building.
The engagement is an architecture review and specification. You bring the system. I tell you where the interfaces are underspecified, where the cross-layer dependencies are undocumented, and what needs to change before the next hardware spin costs you a revision cycle.
The first 30 minutes are free. No pitch, no prep required. Just bring the system.
The building is yours. The blueprint is mine.
What I actually use.
Mechanical and electronics design
Firmware and software
Wireless and connectivity
Project and product management
Architecture documentation is written in markdown, versioned in git, and lives next to the code it describes. The most important tool on any project is a clear interface specification document that the firmware team and the electronics team have both read, agreed to, and will actually hold each other to.