The First Time Someone Paid for My Code

Last month I started taking freelance development jobs. The motivation was simple — I wanted to know if my skills were actually worth anything.

When the first payment came through, the feeling hit harder than I expected.

It wasn’t about the amount. It was what it meant. A stranger, who knew nothing about my background or age or transcript, looked at my code and decided it was worth paying for.

That’s a different kind of validation. Not like getting a grade back, not like a teacher saying “nice work.” This was the market giving you feedback — someone had a real problem, they trusted you to solve it, and they backed that trust with money.

In that moment I felt like my reason for learning to code finally crystallized. Not for grades, not for another line on a resume. Because I can use this skill to genuinely help people, and people recognize that value.

But the real growth didn’t come from being validated. It came from getting reality-checked.

When you build side projects, you define the requirements. You are the user. Anything goes. Once I started taking client work, I discovered that clients care about things I’d never even considered.

It wasn’t technical challenges. It was cognitive blind spots.

The things I thought were important — architecture, code elegance — clients often didn’t care about at all. The interaction details clients kept emphasizing, I initially dismissed as trivial. It’s not about who’s right or wrong. It’s about having different perspectives. When you work on your own projects long enough, you unconsciously start living in a bubble where you assume “reasonable requirements should look like this.” Real clients pop that bubble.

Outside my own frame of reference, there are needs and insights I’d never see from inside my own projects.

The most painful lesson was about communication.

One job, I thought the requirements were clear enough, so I just started building. Got most of the way through before realizing what the client wanted and what I’d understood were slightly different. Not the big picture — the details. I had to redo a fair amount of work.

That experience taught me a principle: pin down the shape of the project before you write a line of code.

Communicate more. Confirm more. Ask “is this what you mean?” even when you think you already know. Because “I think it’s clear” and “we both understand the same thing” are two very different states. Rework always costs more than one extra question.

Now my process is: talk through requirements until both sides feel there’s zero ambiguity. Then build a minimal prototype for the client to validate direction. Only then do I start real development. Two extra steps, but they save hours of rework.

What freelancing taught me that school can’t:

Your skills are worth what someone else decides they’re worth. Your perspective has boundaries, and real-world demands will help you expand them. And communication isn’t a “soft skill” — communication is part of engineering. Communication failure equals delivery failure.

I’ll keep taking jobs. Not for the money. Because every project forces me out of my comfort zone.