What 6 Months of Client Work Actually Taught Me

I shipped a fintech CRM, a film production SaaS, a roofing CRM, and a handful of smaller things — all in roughly six months. Most of it while studying for exams. And while I'm proud of what got built, the actual education came from everything around the code.

Here's what I actually learned.

A verbal agreement is not a contract

This one hurt.

I had a clear mental model of what a project included. The client had a different one. Neither of us had written it down. When it came time to settle up, we were comparing two different versions of the same project that had never been formally aligned.

The lesson isn't "clients are dishonest." Sometimes they are. More often, scope just drifts and nobody tracks it. By month four, a project that started as ten features had quietly become fifteen, and I was absorbing the difference.

Now I scope in writing before I touch anything. Not because I distrust people, but because future-you and future-them will both misremember differently.

Middlemen have their own interests

I worked through an agency that sat between me and the end clients. That arrangement has real benefits — they handle acquisition, I focus on building. But it also means you're always working with a filtered version of what the client actually wants, and you're always paid by someone whose margin depends on paying you less.

It took me longer than it should have to see that clearly. Not because it was hidden, but because I kept assuming the interests were aligned when they weren't really.

If you work through a middleman, that's fine. Just be honest with yourself about the dynamic.

Scope creep happens in both directions

Everyone talks about clients adding features without paying more. Less talked about: developers building things that weren't asked for.

I over-engineered stuff. I added polish nobody requested. I spent hours on features that sounded impressive but weren't in scope. Partly perfectionism, partly wanting to show what I could do. It cost me time and made project estimates messier.

Good enough — actually good enough, not lazy — ships faster and leaves less room for scope arguments later.

"80% complete" means different things to different people

On one project, I thought the core deliverables were done. The client thought the project was barely started, because they were measuring against a different list of features. Neither of us was lying. We just had never sat down and agreed on what "done" looked like.

Now I define done before I start. Milestone by milestone, feature by feature. It's annoying to write up front and worth every minute.

The work is maybe 60% of the job

This was the most uncomfortable realization. I got into this because I like building things. But running client projects means you're constantly doing other stuff — writing updates, managing expectations, defending your estimates, figuring out what was actually agreed six weeks ago.

None of that's bad. It's just different. And if you resent it, you'll do it badly.

The developers who burn out aren't usually the ones who write bad code. They're the ones who treat communication as a tax on the real work instead of part of the job.

Six months taught me that the technical side is the part I have the most control over. The rest — contracts, relationships, scope, payment — needs just as much attention, maybe more. I don't think I'll stop making mistakes, but at least now I'm making different ones.