Skip to content
WildanNiamStart a conversation

Navigate

Software systems, documentary proof, and the decisions behind the build.

About

I make ambitious systems easier to see.

Software Engineer building AI agents and Web3 systems.

Bandung, Indonesia

Wildan wearing a maroon jacket and event lanyard in an indoor venue.
Portrait of Wildan at a technology event in Bandung.

I build inspectable software systems that turn ambitious AI and Web3 ideas into working product flows, then document the decisions and evidence behind them.

I am a Software Engineering student at Telkom University who learns by building systems with real constraints. My favorite projects sit where product behavior and technical architecture have to agree: an AI agent that should help without taking custody, a payment flow that needs a receipt, or a Web3 action that should be understandable before someone signs it.

I usually work across the stack, but I do not treat full-stack work as a claim that one person did everything. The strongest hackathon projects here were team efforts. I like leading the product direction, connecting specialist contributions, and making the final path coherent enough for a user, teammate, or reviewer to inspect.

That working habit also shapes my research into LLM-assisted self-healing test automation. Before asking an intelligent system to act, I want the failure, decision boundary, and recovery evidence to be visible. The same principle appears in Fradium, Nova, PayGate, and Quorum in different forms.

This portfolio is a living record of that practice. Some projects are hackathon artifacts, some are research, and PayGate is an active product build. I present each one with its actual state, the role I held, the people around it, and the proof that survives after the demo.

Based in
Bandung, Indonesia
Studying
Software Engineering, Telkom University
Open to
Open to software engineering roles, research collaboration, ambitious product teams, and focused builder programs.

Working principles

  1. Make the boundary visible.Users should know what the system did, what it did not do, and where their decision still matters.
  2. Keep evidence close.Product behavior, source, transactions, tests, and team outcomes become more useful when their context stays attached.
  3. Build with the team in frame.Leadership means making the shared build coherent while keeping specialist contributions clear.