Hi, I'm Jhelan.
I connectautomationdatauntil ideas become products.
Mechanical engineer by training. Builder by instinct. I like figuring out how things work — then making them work better.
About
Engineering, in every form.
I started in mechanical engineering — mechanisms, forces, constraints, and things you could sketch, test, break down, and reason about from first principles.
For me, engineering is sense-making: understanding the world deeply enough to build better systems inside it.
That way of thinking pulled me beyond one discipline. Machines led to software. Software led to cloud, data platforms, AI, and product systems. Different materials, same instinct: understand the primitive pieces, then connect them into something better.
I try not to rush toward the obvious fix. I prefer solution-neutral problem framing: understand the real problem first, separate symptoms from causes, map the constraints, then decide whether to reuse, adapt, or build from scratch.
I enjoy the messy middle — blank canvases, unclear requirements, half-formed ideas, and problems where the answer has to be discovered rather than copied. That is where engineering feels most alive to me.
Today, that shows up as platform engineering, data systems, full-stack product work, and AI tooling. But underneath it all, I still think like someone looking for the mechanism — whether it is physical, logical, operational, or organizational.
Process
How an idea becomes a system.
This is roughly how I move from a fuzzy problem to something that ships. Click a step to walk through it.
Think slow. Build fast — especially with AI in the loop once the model is clear.
Step 01 · Input
Start with the mess
A vague problem, conflicting symptoms, half-formed requirements, or a tool that somehow became critical. I sit with the ambiguity before touching a stack.
Rules of thumb
Short list. Long memory.
These are the ones I actually come back to.
AI for speed, not for skipping thought
I use AI to implement fast once the architecture and boundaries are clear — not to avoid understanding the problem.
The map matters more than the stack
Tools change. Knowing how the pieces connect — and where they break — does not.
Clever in design, boring in production
If a system needs heroics to operate, the design was probably showing off.
Name things properly
Bad naming is a tax you pay forever. Services, permissions, env vars, docs — all of it.
Code
Things I build to think out loud.
Experiments, tools, and side projects where I try ideas before they become anything bigger. If you want to see how I think in practice, GitHub is the place.
Most of my repos started as a question I could not stop turning over.
- Platform and backend experiments
- Data tooling and automation
- AI and retrieval prototypes
- Full-stack ideas worth exploring
Stack
Tools I reach for.
Different layers, same game — boundaries, contracts, state, and failure modes.
Frontend
Backend
Cloud & Platform
Data & AI
How I work
Connect
Always happy to talk about interesting builds.
If you are working on something you care about and want to compare notes, swap ideas, or just geek out about how something should work, say hi on LinkedIn.
A messy idea, a half-formed tool, a problem you keep circling — those are my kind of conversations.