Three months.
One client.
A complete agency dashboard.
And $200 paid out of an agreed $1,500.
I didn't lose those three months because the project was technically difficult.
I lost them because I approached freelancing like a developer instead of a business owner.
There was no signed contract.
There was no clearly documented payment schedule.
And when the project was finished, I didn't push for the remaining balance.
I simply moved on.
A year later, I still haven't received it.
Surprisingly, I'm not writing this article because I'm angry about it.
I'm writing it because the experience changed how I approach freelance web development.
The Project
The client ran an agency and wanted an internal dashboard to make some of their day-to-day work easier to manage.
The project involved several areas of their business.
There was client management.
There was blog management.
There was work related to SEO.
And there was the usual collection of smaller workflows that appear once you start building software around an actual business.
We agreed on a price of $1,500.
I received $200 upfront.
Then I started building.
From a development perspective, this was the kind of project I enjoyed.
It wasn't just a landing page or a simple CRUD application.
The software had to reflect how the agency actually worked.
That meant understanding their workflow, translating it into features, building the dashboard, adjusting things along the way, and making the application useful for the people who would actually use it.
So I kept going.
And I kept improving it.
For roughly three months, I worked on the project.
Eventually, the work was finished.
The application existed.
The features were there.
The client had what we had discussed.
But there was still one problem.
The remaining $1,300 never arrived.
I Was Too Easygoing About It
This is the part where I could simply blame the client.
But that wouldn't tell the whole story.
The client was responsible for paying the agreed amount.
I was also responsible for how I handled the business side of the project.
I didn't sign a contract.
I didn't establish a formal payment schedule.
I didn't clearly define what would happen if payment was delayed.
And perhaps most importantly, I didn't make payment a condition of continuing the work.
I was focused on building the software.
I thought:
"Let's get the project done."
That mindset is useful when you're trying to be a reliable developer.
It's not enough when you're running a freelance business.
Being easy to work with is good.
Being so easygoing that important business details become vague is not.
That's a distinction I didn't fully understand at the time.
The Developer Mindset vs. The Business Mindset
As developers, we're trained to think in terms of problems.
A client has a problem.
We come up with a solution.
We build it.
We test it.
We fix bugs.
We deliver it.
That's the part we naturally focus on.
But freelance development has another layer.
There is scope.
There are milestones.
There are payments.
There are approvals.
There are deadlines.
There are responsibilities on both sides.
None of these have much to do with whether you can write good code.
But they can determine whether a freelance project is actually successful.
That was the counterintuitive part for me.
I used to think that being professional mostly meant doing excellent work and being dependable.
It does.
But professionalism also means making expectations clear.
I Didn't Need a Complicated System
Looking back, I didn't need some sophisticated legal or financial system.
I needed basic structure.
Before starting the project, I should have had a written agreement covering things like:
- What exactly I was building
- What was outside the scope
- The total project price
- The payment schedule
- What the upfront payment covered
- When the remaining balance was due
- How additional work would be handled
- What happened if the project was paused
None of this has to make a client relationship cold or transactional.
In fact, I think the opposite is true.
Clear expectations make collaboration easier.
When both sides know what they agreed to, there's less room for confusion later.
The $200 Changed How I Look at Upfront Payments
The $200 upfront payment was important for another reason.
It showed that the client was willing to invest in the project.
But it wasn't enough to protect me from continuing too far without another payment milestone.
If I were handling the same project today, I would structure the payments around the work.
For example:
Initial payment → project begins
Milestone payment → major functionality completed
Final payment → final delivery
The exact percentages aren't the important part.
The principle is.
Don't let the entire financial risk sit on one side of the relationship.
I Also Learned Not to Confuse Kindness With Avoiding Difficult Conversations
This was probably the hardest lesson.
I didn't confront the situation.
Not because I thought the remaining payment was unimportant.
I just didn't want to create conflict.
So I stayed quiet.
Eventually, enough time passed that I stopped thinking about it.
A year later, the project is simply something I remember as an expensive lesson.
And honestly, I'm okay with that.
I would rather take the lesson than keep resentment over the money.
But if I could go back, I would handle the conversation differently.
Being respectful doesn't mean avoiding uncomfortable conversations.
You can be polite and still be assertive.
You can value the relationship and still set a boundary.
You can be flexible without making the agreement one-sided.
That's something I understand much better now.
The Project Still Taught Me Something Technically
It's easy to focus on the unpaid balance and forget the actual development experience.
But the project itself was valuable.
I got to work closely with an agency and build software around its internal workflow.
I worked on client management.
I worked on content and blog-related functionality.
I was involved in SEO-related work.
And I learned more about how businesses actually use software than I would have from another isolated personal project.
That's one reason I don't consider those three months completely wasted.
The money was never recovered.
The experience was.
And I still use what I learned from it.
What I'd Do Differently Today
If I started the same project today, my approach would be different.
I'd still listen carefully to the client.
I'd still try to understand the business before writing the first feature.
I'd still go out of my way to make the software useful.
But I'd also make the business side explicit from the beginning.
I'd document the scope.
I'd agree on milestones.
I'd use written communication for important decisions.
I'd make payment expectations clear.
And I'd stop treating conversations about money as something separate from professionalism.
Because they're not.
If you're providing a professional service, getting paid is part of the project.
The Lesson Was Worth More Than $1,500
I didn't get the remaining $1,300.
I can't go back and change that.
But I can make sure I don't repeat the same mistake.
The biggest lesson wasn't "don't trust clients."
It wasn't "always expect people to avoid paying."
And it definitely wasn't "be difficult to work with."
It was much simpler:
Good relationships need clear expectations.
A good client relationship isn't built by one person constantly being flexible.
It works when both sides understand their responsibilities and respect them.
That's reciprocity.
And that's something I wish I'd understood earlier.
Today, when I build software for a client, I think about more than whether the feature works.
I think about whether the scope is clear.
Whether expectations are documented.
Whether both sides know what happens next.
And whether I'm taking care of my responsibilities as both a developer and a business owner.
Because becoming a better freelance developer isn't only about writing better code.
Sometimes, it's about learning when to stop coding, have the conversation, and protect the work you've already done.
That lesson cost me $1,300.
I think it was worth learning.
> I'm Ayman Atif, a backend engineer and full-stack developer building production-ready web apps and tools. You can explore my work and latest projects at ayman-atif.vercel.app.
Top comments (0)