My first paid client project was JavaSourceCode — a study resource website — and I said yes to it before I'd really thought through what "client work" actually meant. I assumed it would be like my personal projects, just with someone else's name on it. I was wrong in almost every useful way.
Scope creep is real, and it's nobody's fault
The original brief was simple: a study site with notes, videos, and past papers, no login required. Within two weeks it had grown to include category filters, a search function, and a request for "maybe some sort of admin panel eventually." None of these requests were unreasonable — they were just undocumented. I learned quickly that the fix isn't refusing new ideas, it's writing everything down and being upfront about what fits in the current phase versus a future one.
Communication is the actual job
I used to think freelancing was 90% code and 10% talking to the client. It's closer to the reverse. Most of the friction in that first project came from assumptions I hadn't checked — I assumed "professional" meant one thing, the client meant another. A five-minute clarifying call would have saved hours of rework.
The client isn't rejecting your code. They're telling you what you didn't ask about earlier.
What I do differently now
- I confirm scope and structure in writing before opening my code editor.
- I share progress in small increments rather than disappearing for a week and delivering a "surprise."
- I ask about the non-obvious constraints early — who else needs to update this content, and how technical are they?
JavaSourceCode is still live today, and it remains one of the projects I'm proudest of — not because the code was perfect, but because it's where I actually learned how to work with another person's expectations instead of just my own.