A portfolio and shadcn registry showcasing my work as a Software Engineer.
A button that works with a mouse but loses its focus state when you use a keyboard bothers me. So does an animation that takes too long, or a CLI that gives you an error without telling you what went wrong.
I like working on those details. The ones that don't always make it into a feature list but change how software feels to use.
Hey, I'm Raditya, a software engineer based in Tangerang, Indonesia. Welcome to my little corner of the internet.
Why I made this place
A project card can tell you what I built. It can't tell you much about how I think, what I changed halfway through, or why I spent time fixing something most people wouldn't notice.
That's what I want this site to make room for.
You'll find my projects here, of course. But you'll also find components you can try, code you can inspect, and notes on decisions that didn't fit neatly into a README. I want to keep the interesting parts of the process visible, including the parts I later decide to redo.
Things you can actually use
I enjoy building interfaces, especially the bits where design decisions turn into working code. A good interaction should make sense with a keyboard, survive a smaller screen, and still feel right when the animation is turned off.
The blocks and components on this site are a place for those experiments. Some are small interactions; others are pieces of an interface you might want to use in your own project. The shadcn registry makes it easier to take a closer look at the implementation instead of stopping at a screenshot.
My projects go beyond the browser, too. There's Repolith, where I explore software collaboration and repository workflows; Kalt Code, a terminal-first AI coding agent; and CacheReap, a CLI for cleaning up development caches. Different problems, but they all give me reasons to think about how developers actually use their tools.
What I'll write about
Expect practical notes from whatever I'm building: an SVG that was harder to get right than it looked, a design detail worth keeping, a technical decision I changed my mind about, or a bug that taught me something useful.
I don't want every post to read like a tutorial. Sometimes a short explanation and a bit of code are enough. Other times, a problem deserves a proper breakdown, including what I tried before finding something that worked.
I'll keep the writing close to the work. If I recommend an approach, I want to explain its trade-offs. If a project changes direction, I want to be able to say why.
See you around
This site will change as I build more things and learn to build them better. That's part of the appeal of having a place I can edit myself.
Have a look around. Try a component, open a project, or read through the code. And if you spot a rough edge, I'd genuinely like to hear about it.
Thanks for stopping by.
Raditya