I spend a lot of time building things, but very little time writing about the decisions behind them. This blog is my attempt to change that.
I’m Abhinav, a developer and designer from Nepal. I work across product design and engineering, and I run Klivo Studios - a software development agency that builds products, tools, and custom solutions to improve day-to-day business operations. Most of my days involve turning an idea into something people can actually use - planning the experience, making technical decisions, writing the code, and handling all the less-visible details between a first sketch and a working product.
That process creates plenty of useful lessons. Until now, most of them have stayed inside project notes, commit histories, or my own head. Writing gives me a reason to slow down, examine those lessons, and explain them clearly.
What I’ll write about
This will not be a stream of polished success stories. I want it to be a practical record of the work: what I tried, what worked, what failed, and what I would do differently next time.
You can expect posts about:
Building web and mobile products from early ideas to launch
Design decisions that make software clearer and easier to use
Frontend and backend architecture without unnecessary complexity
Lessons from building products such as Relay CMS, Flux, and AineBMS
Running Klivo Studios and improving the way I work with clients
Tools, experiments, and ideas that are worth exploring
Some posts will be technical. Others will focus on product thinking, design, or the business side of building software. The common thread will be direct experience rather than abstract advice.
Why write publicly?
Publishing creates a useful kind of pressure. It forces vague thoughts to become specific. If I cannot explain why I made a decision, I probably have not understood it well enough.
It also creates a record. Products change quickly, and it is easy to forget why an earlier version looked or worked a certain way. A written explanation preserves the context that screenshots and source code often miss.
Most importantly, I have learned a great deal from developers and designers who shared their process openly. If something I write saves another person a few hours, helps them avoid a mistake, or gives them a better starting point, then publishing it was worthwhile.
I don’t want this blog to present finished work without showing the thinking, uncertainty, and trade-offs behind it.
Keeping it useful
I want the writing here to follow the same principles I value in products: clear, practical, and intentional.
That means avoiding inflated claims, unnecessary jargon, and advice presented without context. I will show the constraints behind decisions and be honest when an approach is still experimental.
There is rarely one correct way to build something. There are usually trade-offs that make sense for a particular team, product, and moment.
The starting point
This portfolio redesign feels like the right place to begin. It is not only a new coat of paint - it is a clearer home for my work, the products I am building, and the ideas I want to develop further.
The blog will grow alongside that work. I do not plan to publish for the sake of maintaining a schedule. I would rather write when I have something concrete to share and make each post worth reading.
For now, this is the first entry: a small commitment to document more, explain the work better, and keep learning in public.
Thanks for being here at the beginning.