Welcome
Welcome — why I build projects in public
A note about turning curiosity into useful products, learning through real constraints, and sharing the honest path from idea to launch.
I build projects because making something real is the clearest way I know to turn curiosity into understanding—and understanding into something useful for other people.
Projects make learning honest
Tutorials can make every decision look inevitable. A real project removes that illusion. Users arrive with needs you did not predict, APIs fail, simple features reveal awkward edge cases, and the trade-offs become concrete. Building forces me to test what I think I know against reality.
That is the purpose behind these projects: not to collect launches, but to develop judgment. Each product is a small laboratory for product thinking, design, engineering, and the less visible work of deciding what is worth building at all.
Building should leave a trail
I am publishing the reasoning as well as the result. That means documenting the first sketch, the architecture that changed, the feature that did not work, and the lesson that only appeared after shipping. The polished launch is useful; the path to it is often more reusable.
This blog is that trail. It will connect project notes with focused learning series so a reader can move from a concept to the place where it shaped a real implementation.
“The goal is not to look finished. The goal is to keep becoming more capable—and make that process useful to someone else.”
Start with the system underneath
The first learning series is a ten-day introduction to system design. It begins with a single request, then adds estimation, networking, data, caching, queues, scale, and reliability. The final day combines every layer in a URL shortener design.
You can read one lesson a day or move at your own pace. Every entry links backward to the idea it builds on and forward to the concept it unlocks. Start with Day 1, keep a notebook, and redraw each system in your own words.