Hello, world. I finally started a blog.
An intro to who I am, what I'm learning, and why I'm writing this in public instead of in a private notebook.
Read postSearch across posts, tags, and categories.
Introduction
Introduction
When I began building muniba.dev, I wasn't chasing the idea of launching just another website.
I wanted something personal.
A place to keep track of what I was learning, write about modern web development, and share the projects I was building as I went.
Once the site was ready with Next.js and Nextly handling the content, there was only one thing left.
Deployment.
I'd seen enough stories from other developers. Builds that failed for no obvious reason. Projects that worked perfectly on a laptop, then refused to cooperate in production. Server headaches. The usual stuff.
So yeah, I expected the worst.
I was wrong.
My first deployment with Vercel changed that expectation almost immediately.
Connecting My Project
It started with connecting my GitHub repository.
That was it.
Within seconds, Vercel recognized the project as a Next.js application and filled in the deployment settings on its own. No hunting for build commands. No digging through server configuration. I just connected the repository and watched everything fall into place.
Honestly, that surprised me.
Instead of spending an afternoon configuring infrastructure, I went back to improving my website and writing the next article I wanted to publish.
Seeing muniba.dev Go Live
Watching the deployment progress felt oddly exciting.
Then it happened.
A few moments later, muniba.dev was live.
Opening my own developer website and knowing anyone could visit it from anywhere felt different than I expected. It wasn't simply about putting a site online. It felt like opening the door to my work, my projects, and everything I was learning along the way.
That's the moment that reminded me why I wanted to build in public in the first place.
Learning Along the Way
Of course, nothing is perfect.
My first deployment came with a few bumps. I missed some environment variables, ran into build errors, and quickly learned that production behaves differently from local development.
At first, it was frustrating.
Later?
Those mistakes became some of the best lessons from the entire project. Every fix taught me something new about deployment, and every successful update made me a little more confident the next time I pushed changes.
What I Like About Vercel
After deploying muniba.dev, a few things stood out almost immediately.
Automatic deployments every time I push changes to GitHub.
Preview deployments that let me check updates before anyone else sees them.
Simple environment variable management.
Great support for Next.js projects.
A clean dashboard that's easy to understand at a glance.
Those features mean I spend less time thinking about hosting and a lot more time building features and writing content.
Which is exactly where I want my attention.
Final Thoughts
Before trying Vercel, I assumed deployment would become one of the hardest parts of building a web application.
Instead, it became one of the easiest.
Now, whenever I publish a new feature or write another post on muniba.dev, I know getting those changes online only takes a few clicks.
That makes a difference.
It gives me the confidence to keep experimenting, keep improving the site, and keep building in public because deployment is no longer something I worry about.
An intro to who I am, what I'm learning, and why I'm writing this in public instead of in a private notebook.
Read postA short argument for shipping small projects to a public URL, even when they are embarrassing.
Read post