3 Clients Fired Us Last Year. Here's What Each One Taught Me.
I want to start with the uncomfortable part: in 2025 we lost three clients. Not because the work was bad — actually I think the work was fine in two of the three cases. We lost them anyway. I've been turning over what happened in each of them for the last few months, and I think I finally understand what each one was trying to teach me. This is the version I wish someone had written for me five years ago.
Names changed. Industries kept real. Numbers in INR are real.
Client one: the DTC fashion founder who 'just had a quick question'
She was running a small but growing direct-to-consumer fashion brand from Bandra. Smart, very fast moving, beautiful brand, the kind of founder you wanted to keep working with for a decade. We won the project at ₹4.2L for a Shopify Plus migration plus three months of post-launch development.
Things were going well. Then around week three of the migration, we got the first 'just a quick question' on WhatsApp at 9pm. Could we add a custom waitlist module? Sure. Could we add multi-currency? Yeah, we can do that. Could we slot in a pre-order flow before launch since their summer drop date had moved up? Of course.
By week six, the contract had silently grown by what I now estimate was about 80 hours of unbilled work, and the launch had slipped two weeks. She fired us in a single email a week before the new launch date. Her team had hired an in-house developer the week before; we'd been retained while they negotiated.
What I learned
The mistake wasn't agreeing to the extra work. The mistake was not pricing it the moment she asked. Every 'quick question' should have been answered with the same line: 'Yes, that's roughly two days of work and ₹X — should I add it to the SOW or do you want to defer to phase two?' Putting a price on every request — even a small one — does two things at once: it slows down the request flow naturally (because most quick asks are not worth the cost), and it makes the eventual end-of-month invoice unsurprising. Founders fire freelancers over surprise. They almost never fire over invoices that match what was discussed in WhatsApp.
After this, we changed two things. First, every WhatsApp scope-question now gets a written reply with a price and a timeline before the work starts — even informal ones. Second, our SOWs now have a 'change request' clause with a flat hourly rate so neither side has to renegotiate when small things come up.
Client two: the agency-of-an-agency we should have walked away from on day one
A mid-size US digital agency hired us as a subcontractor for a Laravel admin panel for one of their enterprise clients. ₹6.8L, four months. Seemed clean: well-defined deliverables, professional brief, native English communication, a clear PM on their side.
The first warning sign was that the PM changed in the second week. Then again in week five. Each new PM had a slightly different read on what we were building. We documented every requirement change in writing and got sign-off, which felt like the responsible thing to do. By month three the document was 47 pages long, contradicting itself in eight places, and nobody on their side was willing to be the one to break the tie. The end client got frustrated, blamed the agency, the agency blamed us, and we got cut from the project with two weeks left.
We did get paid for everything we'd documented. The frustrating part wasn't the money — it was that we'd shipped something that nobody on the client side seemed to want anymore.
What I learned
Agency-of-an-agency relationships are structurally fragile. We were three layers removed from the actual decision-maker, separated from the people who would use the software by their PM, who was separated from the client by their account manager, who was separated from the user by the client's internal politics. Every misalignment in those layers compounds.
The lesson isn't 'never subcontract.' We still take subcontracting work. The lesson is: insist on a single human on the client side who has decision authority, and refuse to start work if you can't get that person on a 30-minute call before the contract is signed. If the agency won't connect you, the project is already broken — they're hiding the actual decision-maker, usually because they don't have a clear answer themselves.
We've turned down two subcontracting opportunities since this one because we couldn't get the call. Both came back later under different terms.
Client three: the founder I was wrong about from the start
This is the one that still stings the most.
An early-stage founder reached out wanting a Next.js + Stripe MVP for his SaaS idea. ₹3.5L, ten weeks. He was smart, had a real-sounding pitch, and the technical scope was straightforward. We took it.
By week four it was clear the product idea was changing every Monday. Not pivoting in the small, real way that good founders do — fully different products, different target users, different value props. We tried to rebuild around each new direction. Around week seven he called and told me, in genuinely friendly terms, that he was killing the project and shutting the company. He wasn't going to launch anything. He paid out the contract in full and that was that.
It cost us nothing financially. We delivered nothing useful to the world. That's the part I've been chewing on.
What I learned
I should have refused this engagement on day one. Not because of the money — at ₹3.5L it was fine. Because of a thing he said in our first call that I rationalized away: 'I'm not totally sure what we're building yet, but you guys can figure that out, right?'
What he meant was: 'I want a developer to also be my product manager.' What I heard was: 'this is a flexible project, we can adapt.' Those are very different things. Developers can be flexible inside a known product. We cannot be flexible about WHAT the product is. That's the founder's job. If the founder doesn't know what they're building, no amount of well-written code can save the project.
Now we have a screening question on the first call: 'Can you tell me, in one sentence, who will use this product and what problem it solves for them — without using the words AI, platform, or solution?' If the answer takes more than three minutes or doesn't end up at a clear sentence, we either decline or scope only a discovery phase first. That single question would have saved us seven weeks of work that helped no one.
The pattern across all three
Looking back, all three engagements ended for related reasons that I've come to think of as 'unspoken expectations.'
- Client one: she expected scope flexibility without price flexibility. We let her have that for too long.
- Client two: the agency expected a stable spec but couldn't internally produce one. We accepted it anyway.
- Client three: the founder expected us to also be the product designer. We didn't push back.
In every case, the expectation gap was visible on the first call. In every case, I rationalized it because the project looked attractive. The pattern wasn't bad clients. The pattern was me wanting the work badly enough to not push back.
“Most failed engagements aren't failures of execution. They're failures of agreement-on-day-one.”
What changed for us
Concrete things we do differently now, partly because of these three:
- Every change request — even a one-paragraph WhatsApp ask — gets a price and a timeline in writing before work starts.
- We don't take subcontracting work where the actual decision-maker won't get on a 30-minute call before signing.
- Every first call now ends with the 'one-sentence product' test. If it doesn't pass, we scope a discovery phase first instead of full delivery.
- We say 'no' or 'not yet' twice as often. Not because we're picky — because losing a fit-and-finish week to the wrong client costs more than losing a whole month to a clear-fit one.
What I'd want a client reading this to take away
If you're considering hiring a freelance team, the most honest signals you can give us are these: a one-sentence product description, the budget you can actually defend to your cofounder or board, and the name of the person on your side who will own decisions. If you can give us those three things on the first call, we will be happy to work with you and the chances of an early breakup are very low. If you can't, that's not a deal-breaker — but it means a discovery phase before delivery is in your interest, not just ours.
I'm sharing this less for SEO and more because every founder I talk to thinks they're the exception to these patterns. They're not. None of us are. The people who succeed long-term aren't the ones who avoid the pattern — they're the ones who name it out loud on day one.
Want a no-pitch 30-min call to scope your project properly?
Book the Free CallFounder of buildbyRaviRai, a freelance web development agency based in Noida, India. 5+ years shipping Next.js, WordPress, Shopify, and Laravel projects for clients in India, USA, Canada, and the UK.
Keep Reading
Building an EV Charging Station with RFID Authentication: What We Learned
A practical, opinionated guide for anyone building or operating EV charging stations in India — how the RFID + OCPP stack actually fits together, what hardware works, what breaks in production, and what it costs.
Claude Code vs Human Developers: Where Each Actually Wins in 2026
An honest look at where AI coding tools like Claude Code have genuinely replaced freelance developer work, where they haven't, and how we actually use them on client projects at buildbyRaviRai.