DEV Community: Dhruv Mevada

From 'localhost' to My Own Domain: Publishing My First Portfolio

Dhruv Mevada — Fri, 07 Aug 2026 10:12:51 +0000

For the longest time, my projects only existed on my laptop.

Every time I wanted to show something, I'd send a GitHub link or a few screenshots and say, "Imagine how it looks when it's running."

This week, that finally changed.

I published my very first portfolio website with my own custom domain.

It sounds like a small milestone, but the journey to get there taught me far more than I expected.

The Fun Part

Building the portfolio was enjoyable.

Designing the UI, making it responsive, polishing animations, adding SEO, and making sure everything looked clean—it felt like putting together something that genuinely represented me.

Eventually, I reached the point every developer waits for:

"Time to deploy."

I thought I was almost done.

I wasn't. 😅

Deployment Is a Different Skill

Writing code and deploying code are two very different things.

The application worked perfectly on my machine.

Then deployment reminded me that the internet has its own rules.

Suddenly I was learning about things I'd only heard of before:

DNS records
Custom domains
Static exports
Build pipelines
Framework compatibility
SSL certificates
Hosting platforms

Every time I fixed one issue, another one showed up.

Sometimes it was a configuration mistake.

Sometimes it was a version mismatch.

Sometimes it was simply me misunderstanding how the deployment process actually works.

What I Learned

This experience changed the way I look at software development.

A few lessons really stood out:

Building an application is only part of the journey.
Understanding deployment makes you a much better developer.
Reading documentation carefully saves more time than guessing.
Error messages are frustrating... but they usually tell you exactly what's wrong.
Small configuration changes can completely change how an application is deployed.

The Best Moment

Eventually, everything came together.

Typing my own domain into the browser and seeing my website load for the first time felt incredibly satisfying.

Not because the portfolio is perfect.

It isn't.

There are already features I want to improve, animations I want to refine, and projects I want to add.

But it's live.

It's something I built from scratch and shared with the world.

That feeling is hard to describe.

What's Next?

This isn't the final version of my portfolio.

It's Version 1.

I'll keep improving it as I learn new technologies, build more projects, and grow as a developer.

I like the idea that my portfolio can evolve alongside my journey.

Final Thoughts

This experience reminded me that software development doesn't stop when the code compiles.

Getting an application into the hands of real people is a skill of its own.

If you've been putting off deploying your own website because it feels intimidating, I'd encourage you to do it.

You'll probably run into unexpected problems.

You'll probably spend more time debugging deployment than you expected.

But you'll also learn things that no tutorial can truly teach.

And when you finally see your own website live on your own domain...

It's worth every minute.

Thanks for reading! ❤️

I'd love to know:

What was the biggest challenge you faced while deploying your first project?

Day 1 of Learning Go: Variables, Data Types, and My First Impressions

Dhruv Mevada — Thu, 30 Jul 2026 10:57:28 +0000

I've decided to start learning Go.

My goal isn't just to learn another programming language—it's to become a better backend developer. Over the next few months, I'll be documenting everything I learn, the mistakes I make, and the projects I build.

This is the first post in that journey.

Why Go?

Most of my experience has been with Flutter and Dart, so I've spent a lot of time building mobile applications.

Recently, I wanted to dive deeper into backend development. After looking into different languages, Go stood out because of its simplicity, performance, and strong reputation for building scalable backend services.

So, here we are.

Today's Topic: Variables & Data Types

Like every new language, I started with the basics.

Declaring variables in Go is straightforward.

var name string = "Dhruv"
age := 22

Go also lets the compiler infer the type when it can, which keeps the code clean without losing readability.

The Thing That Surprised Me

I honestly didn't expect Go to have so many numeric data types.

There are signed integers:

int
int8
int16
int32
int64

Unsigned integers:

uint
uint8
uint16
uint32
uint64

Floating-point numbers:

float32
float64

And there are also types like:

byte (alias for uint8)
rune (alias for int32, used for Unicode characters)

Coming from Dart, this initially felt like a lot.

My first thought was:

"Do I really need all of these?"

As I read more, it started making sense.

Different applications have different memory and performance requirements. Having multiple data types gives developers more control over how data is stored and processed.

Small Struggles

Even though variables are one of the first topics in any language, I still had a few moments where I had to stop and think.

Questions like:

When should I use int instead of int32?
Why does Go distinguish between signed and unsigned integers?
What exactly is a rune?
Why is byte just another name for uint8?

These aren't difficult concepts, but they're different enough from what I'm used to that they made me curious.

My First Impression of Go

So far, Go feels...

Simple
Clean
Easy to read
Minimal

There aren't dozens of different ways to write the same thing.

The language feels like it wants you to focus on solving problems rather than learning clever syntax.

I like that.

What's Next?

Tomorrow I'll be learning more Go fundamentals like arrays, slices, functions, and control flow.

Eventually, I want to build real backend projects using:

Go
SQL
Redis
Docker
AWS
CI/CD

I'll be documenting the entire journey here on Dev.to.

If you're also learning Go, I'd love to hear what surprised you when you first started.

See you in Day 2! 🚀

Git Wasn't the Hard Part. Explaining It Was.

Dhruv Mevada — Thu, 16 Jul 2026 07:03:48 +0000

Git Wasn't the Hard Part. Explaining It Was.

I thought teaching Git to my friend would take about 30 minutes.

You know... install Git, create a repository, make a commit, push it to GitHub, and we're done.

Three hours later, we were debating whether the .git folder was a database, a hidden backup, or some kind of developer black magic.

That's when I realized something.

Git isn't hard because of the commands. It's hard because of the way it makes you think.

"If GitHub stores everything, why do I need Git?"

That was the very first question.

Honestly... it's a fair question.

When you've never used version control before, Git and GitHub sound like they're the same thing.

So instead of giving the textbook explanation, I used an analogy.

Your project folder is your notebook.

Git is the history of everything you write in that notebook.

GitHub is Google Drive where you upload that notebook so others can access it.

The expression on my friend's face immediately changed.

"Okay... that actually makes sense."

That was the first small victory.

The Magic of `git init`

We opened a terminal and typed:

git init

My friend looked at me and asked,

"Did anything even happen?"

I smiled.

"Yes."

"But... nothing changed."

"Exactly."

One hidden folder appeared.

That's all.

Yet that tiny hidden .git folder is what transforms an ordinary project into a Git repository.

It's funny how one invisible folder powers the workflow of millions of developers.

The First Commit

We created a simple README file.

git add .
git commit -m "Initial commit"

Another question arrived.

"So... is it online now?"

"No."

"Then where is it?"

"It's safely stored on your own computer."

That was another lightbulb moment.

A lot of beginners assume every Git command uploads their code somewhere.

Understanding that Git works locally first makes everything else much easier.

Connecting to GitHub

We created a repository on GitHub.

Then came the commands:

git remote add origin <repository-url>
git branch -M main
git push -u origin main

A few seconds later, we refreshed GitHub.

The repository appeared.

My friend literally smiled and said,

"Wait... that's my code?"

Yes.

For experienced developers, pushing code to GitHub feels routine.

For someone doing it for the first time, it feels like launching a rocket.

The Questions That Made Me Think

Some of my favorite questions from that session were:

"Why do we need Git if we already save files?"
"What's inside the .git folder?"
"Why isn't my commit visible on GitHub?"
"Why do we need both Git and GitHub?"
"Why do people use branches instead of just making another folder?"

They were simple questions.

But answering them forced me to rethink concepts I'd been using automatically for months.

Teaching Made Me a Better Developer

People often say,

"The best way to learn something is to teach it."

I didn't fully believe that until this session.

When you're using Git every day, commands become muscle memory.

You stop thinking about why they exist.

Teaching someone else made me slow down and understand the reasoning behind every step.

It reminded me that beginners aren't confused because Git is impossible.

They're confused because they're learning an entirely new way of thinking about code.

Final Thoughts

By the end of the session, my friend had:

Installed Git
Created a local repository
Made the first commit
Connected the project to GitHub
Pushed code successfully

More importantly, they understood why each step existed.

And I walked away with something too.

Not better Git commands.

A better understanding of Git itself.

Sometimes the biggest lessons don't come from building software.

They come from helping someone else build their confidence.

Have you ever taught Git to someone?

What was the funniest question they asked? or, if you're just starting out, what confused you the most?

I'd love to hear your stories in the comments.

DEV Community: Dhruv Mevada

From 'localhost' to My Own Domain: Publishing My First Portfolio

The Fun Part

Deployment Is a Different Skill

What I Learned

The Best Moment

What's Next?

Final Thoughts

Day 1 of Learning Go: Variables, Data Types, and My First Impressions

Why Go?

Today's Topic: Variables & Data Types

The Thing That Surprised Me

Small Struggles

My First Impression of Go

What's Next?

Git Wasn't the Hard Part. Explaining It Was.

Git Wasn't the Hard Part. Explaining It Was.

"If GitHub stores everything, why do I need Git?"

The Magic of git init

The First Commit

Connecting to GitHub

The Questions That Made Me Think

Teaching Made Me a Better Developer

Final Thoughts

The Magic of `git init`