How an Abandoned Client Project Became My Proudest Showcase

Question

In the first part of this series, I walked through the technical grit of rebuilding a musician's web platform from scratch—spending over 320 hours fixing legacy WordPress code, writing custom CLI tools with Node.js and FFmpeg, and crafting a lightweight Vanilla JS SPA router.

If Part 1 was about the engineering side, Part 2 is about the human side: scope creep, irrational client expectations, and why finishing an "abandoned" project is sometimes the ultimate test of a developer’s character.

"Appetite Comes With Eating": How a Volunteer Portfolio Case Turned Into Scope Creep

They say the road to hell is paved with good intentions.

We stepped into this project on pure enthusiasm. The agreement was simple: we help an independent artist build a sleek web presence for free, and in return, we get a real-world production case for our engineering portfolios. Win-win, right?

At the beginning, everything was smooth. The client was absolutely thrilled with the initial UI/UX prototypes. But as soon as the application was actually hosted and brought to life, the "appetite" started growing exponentially:

1. Phase 1 (Initial tweaks): "Can we change the album cover art?" — Sure thing. It's your music, your Bandcamp embed—done.
2. Phase 2 (The Breaking Point): "The fonts don't feel right... can we rewrite the copy?"

This was the final straw. Keep in mind: we had repeatedly confirmed typography and styling choices with the client earlier, and everything had been approved.

When my teammate David politely informed the client that fundamental UI changes were outside the scope of our volunteer agreement, the client responded with: "Just show me where the files are, and I'll change the fonts myself."

For anyone who works in web development, this was the ultimate ironic punchline. Changing fluid typography, responsive SCSS breakpoints, and layout variables isn't like picking a font in Microsoft Word. Knowing that the client had previously struggled to set up a basic Bandcamp profile, we wished him the best of luck—and officially closed the client chapter.

And the kicker? The expectation was that all these endless, fundamental redesigns should continue under the same "volunteer" umbrella indefinitely.

"You Live and You Learn": The Hardest Tech Stack is Working With People

Seniors and project managers reading this might smirk: "Well, that’s classic Scope Creep. That's why you need ironclad contracts, strict specs, and change-request fees!"

And you are 100% right. Coming from a non-tech background where I spent years working directly with clients, I already knew that PEOPLE are always the most complex variable in any equation. But experiencing it firsthand as a developer hits differently.

It wasn't just about a client changing his mind; it was about watching a project you deeply cared about get derailed by communication breakdowns. Eventually, the client realized he wanted something completely different, and our custom architecture was left orphaned.

Giving an Orphaned Project a Second Life

At that point, I had two choices:

• Option A: Throw 320+ hours of blood, sweat, and clean code into the dark abyss of a discarded folder and forget it ever happened.

• Option B: Refuse to leave it broken, roll up my sleeves, and transform this project into an independent, high-performance Open-Source Showcase.

I chose Option B.

I spent another full week polishing the codebase, replacing client-specific PII with clean configuration placeholders, refining responsive layouts, writing comprehensive tests, and building a dedicated showcase identity under the D&K Custom Media Platform brand.

If you’re too lazy to dive directly into the GitHub repository, here is a quick 2-minute video walkthrough of what we built:

Conclusion: Even Failures Deserve a Logical Conclusion

Some might say it’s foolish to pour even more time and emotion into a project that failed commercially.

I disagree. You never get anywhere in life—or in software engineering—if you abandon things the moment they get messy. Completing this project gave me something far more valuable than a client's signature:

• A deep, practical understanding of full-stack media pipelines, SPA
  state management, and CI/CD automation.

• Ironclad resilience in handling unexpected project shifts.

• A clean, open-source portfolio piece that I can proudly stand behind.

In the end, every failure deserves a logical, high-standard conclusion. As the saying goes: You’ll never reach your destination if you stop and throw stones at every dog that barks. The code is live, the repository is public, and the work speaks for itself.

Links & Resources:

• 🔗 GitHub Repository: https://github.com/kate8382/custom-media-platform-showcase.git

• 📺 YouTube Video Walkthrough: Watch Here

• 👤 Frontend Developer: Ecaterina Sevciuc (LinkedIn | GitHub)

• 👤 Backend Architect: David H. Watson (LinkedIn | GitHub)