I GOT SCAMMED BY A CLIENT

I got scammed by a client.

It still stings to write that—but it's true.

We took on a full-stack revamp project: new UI, critical bug fixes, backend development—the works. We were a small team of fresh graduates, hungry to prove ourselves. Motivated. Skilled. Optimistic.

And yes—we made mistakes.

The biggest one?

The Fatal Contract Clause

We knew one of the contract clauses was dangerously one-sided:

• •✔️ A full refund if the client was "unsatisfied"
• •✔️ A reimbursement equal to the amount paid
• •✔️ And all work delivered

We questioned it. But we were convinced—internally—that we could deliver, so it wouldn't matter. We signed it.

We were wrong.

The Project Begins

From the start, we were flooded with changes:

• •UI requests that shifted almost daily
• •Design feedback up until the final hours before our delivery window

When we flagged the risk of delay, the client said:

"It's fine. We'll go over the timeline."

So we stayed focused. Built. Delivered.

The Silence

By June 26th, the project was 99% complete. Code deployed. Ready for testing.

Then: silence.

A few days later, while reviewing timelines, we came across something alarming: A new Angular repository on the client's GitHub.

At first glance, it was a different codebase. But it didn't take long to realize—it was a pixel-perfect replica of our work.

• •Same layout
• •Same user flow
• •Same dummy data from our test environment—reused as mock data

They had taken screenshots of our staging site and used AI to recreate the interface in Angular.

The Confrontation

We called a meeting. Presented the evidence.

And the response?

They demanded a full refund, reimbursement, and all the code—for free.

Their justification? That one-sided clause.

The irony? That agreement was never even signed or returned by them. We had followed up—multiple times—and received nothing back. There was no valid contract to enforce.

The Excuses

Then came the excuses.

First:

"Our UI/UX interns rewrote the frontend as an exercise."

Then:

"We're rebuilding it because your code is too complex. We didn't ask for that."

But they did ask for it. In their own words, the agreement stated:

"The Vendor is responsible for implementing industry-standard encryption protocols and ensuring adequate security measures to protect data integrity and platform functionality."

So no—the code wasn't complex for the sake of it. It was secure. It followed standards. It protected data. It was built responsibly.

The Real Problem

What this really showed us? Despite claiming 5–10+ years of experience, their developers didn't know how to work with a secure architecture—so they called it "too complex."

They didn't reject the code because it was wrong. They rejected it because they didn't know how to work with it.

And only after realizing their public repo exposed all of this? Every GitHub repo of theirs quietly went private.

My Response

There was no viable legal route. The paper trail was incomplete.

So I made a choice.

👉 I'm open-sourcing the entire project—fully anonymized.

Not to shame. Not to retaliate. But to move forward—and help others learn from what I didn't catch in time.

Because while the project was taken from us, my values weren't.

The Aftermath

It's been a while since this happened. Their version of the UI we built is still live on their domain to this date. And I can only assume they're still struggling to build the backend we had already completed.

Yes, open-sourcing this might mean they now have access to the backend we originally wrote. But honestly? I don't care anymore.

Any code—no matter how big, no matter how much sweat was poured into it—is never worth compromising your principles over.

If it helps someone else avoid what we went through, then it's worth sharing.

🔗 Here's the project: The Mockify Project – GitHub

We named it Mockify—just the first thing that came to mind. It's a client-specific build, so it likely won't be directly useful to anyone. But if someone finds it helpful as a reference or learning resource, then that's more than enough.

Lessons for New Freelancers

If you're just starting out, here are a few things to remember:

• •Never start without a signed agreement
• •Never accept terms that can be weaponized
• •Never assume trust is a substitute for protection

I lost money. I lost time. But I gained clarity, resilience, and an unshakable sense of how I'll do things moving forward.

To the next client—I'm not just prepared. I'm untouchable.