What to do when your client keeps jacking with the system you developed for them

I've had a client in the real estate training business for six years now. We have an ongoing weekly minimum time arrangement. It's nice knowing there is always X coming in. Over the last several years I have developed a very large LAMP based web-app that is a fully custom LMS with detailed and relatively bulletproof administration management. The bulletproofing is for the client more so than for the students.

This client rarely has time to do things right, often does things incorrectly and never-ever reads my Slack posts about what I'm doing/done. Half my time is fixing their screw ups.

The system is stable and produces hardly three lines or error messages logs a month with thousands of students! That's is something to be proud of I think. This system has gone from barley making a $100K in its first year to now more that $300K annually.

Recently the client has really ramped up "hacking your system" as he fondly calls it. And he has pride saying that too. Most of these hacks are trying to do something the system isn't allowing him to do, for obvious reasons. Mostly they are harmless functionality wise but just screw up style sheets or standards I've tried so hard to limit. (Is that so bad?)

But now he is openly finding ways to bypass functionality because he doesn't like something that has been there for years. This is causing student problems and will eventually cause him twice the setup time for new courses. I have pointed this out many times in many ways. All my warnings have been ignored. The problems are not going to crash the system only screw up students purchases and records. But their trying to fix things could really start to damage data.

What I do not understand is why not just ask the coder to change the functionality to archive the desired result? That's what I'm paid to do, right? I've long since stopped trying to talk them out of inconsequential changes and even some big ones.

We also have a really hard time communicating. Usually they call on their commute so they have to go from memory while driving. Here is a summery of a average conversation:

Client: "I'd like the sky to be red!"
Dev: "Okay, but usually the sky is blue sometimes with white clouds."
Dev: "So, this is how I think I can do this ..."
Client: "No, I'd like the sky red!"

Sorry this is so long. Any advice is greatly appreciated.

  • is this your only client, or do you have multiple clients that make up the 300K revenue?
    – mcknz
    Commented Oct 8, 2020 at 20:04
  • 3
    Does the client have access to the source code of the system and is contractually allowed to change it? If the answer is "yes" , I guess that 's the root cause of your problem.
    – Doc Brown
    Commented Oct 8, 2020 at 20:30
  • Another possibility to consider is that your system (or at least the admin part of it) is not actually well-aligned with their needs and is getting in the way of them doing their work (that the system was supposed to help them do) - which is why they need to hack around it. This could be the case even though you made it for them, perhaps by their specification (clients are bad at writing specs, and they don't actually know what they need from the get go). The only way to find out is to talk to them and/or go there and see the daily and processes and challenges of their work. Commented Oct 8, 2020 at 20:59
  • 3
    Who's system is it really? It sounds like they own it and you are just hired to code in it. It is not workable but ultimately you have a choice: put up with it or walk away. Commented Oct 8, 2020 at 23:01
  • 2
    What is your question? What to do to accomplish what? "It's nice knowing there is always X coming in." What is the problem?
    – philipxy
    Commented Oct 9, 2020 at 4:27

3 Answers 3


Unfortunately the client sees you as a glorified and expensive plumber, except that the plumber actually does something.

He has to get you in so that anyone sticking their nose into it can be pointed at you. But he is of the impression that a little duct tape here will stop that leak, or that he can add a valve there, after all he has read a book on plumbing before.

Now he is certainly making mistakes, and he should redress those.

I could say this is not your fault. But it is.

You have failed to ensure he takes this seriously. He is talking to you while driving a car. He is either going to do someone a mischief on the road, or he isn't paying attention to you. You are a professional, demand to be treated professionally. He would not talk to a lawyer like that. Make sure he doesn't talk to you like that.

Which brings up communication generally. If he isn't reading your slack posts, what are you doing wrong? Is it that he doesn't know how to use slack? Is it that slack does not fit into his daily set of programs well? Are you being too technical? Also if he isn't reading the slack posts, what else isn't he reading? He is probably looking at the total cost on the quote you gave him and thinking too expensive.

So Take some time, study or get training on communicating with a business, practice formal writing, get some oration training, and improve your appearance. Laymen do not know how to assess your leet coding skills, but they can judge your levels of confidence as a proxy.

Its not your system. Its his. Obviously he wants to make changes without having to beseech you for your permission to do so. If you expose some of those decisions to him, he can get his feeling of ownership without breaking the system. Why do you think just about every program has "themes"? They certainly do Zero for the program functionally. Its also why programs provide scripts and hooks for those of a more technical bent.

Fixing their screw ups is part of the job, not the exception. By your own account its half your earnings. If you really don't like this kind of work, renegotiate your fees for fixing these, and limit the times available for doing so. When he has to shell out 20 for what you quoted 2 to implement, or he has to wait till 9am Monday and he screwed it up on Friday night, he's wallet will guide him. You'll be making 10x, he will work with you, or he will never come back (which is always the risk when renegotiating, they can just walk away).

Data gets damaged. As the administrator what have you got in place? Could you restore the database back to pre-incident? Do you have tools in place to refund payments made post-incident? Yes, good. No, get them in place.

You haven't communicated Risk to him. Right now he thinks he is invulnerable, his current cost of hacking in his brain is net positive, and anything that was negative you fixed up and made a positive. So there is no downside in this to him. Try playing a game with him called Production Incident. Make sure the incident involves his hacking, payment information becoming corrupted, and the process for identifying it, restoring service, and then triaging all of the manual work that has to be done to recover the hours lost. This should quickly change his perception of risk in the system. Be prepared though for him to overreact and demand that all changes be SAFE™, which includes your own.

I've been guilty of all the above at one point or another. Experience is a harsh teacher.

The simple point is that you cannot change him, and he is taking full advantage of you.

The only course of action you have is to fix yourself up.

He will either follow, or wander off.

  • Thank you for your in-depth response. After 10 years in Al-Anon I know I can't change him or anyone else. Really good point about themes. Not that's what I need but I completely get it. The Friday night (& Sat, & Sun) had been the norm. He pays me for 15 hours a week regardless. For this guarantee of hours I give him a reduced rate. And yes his constant screw ups are job security :) I have communicated rick to him repeatedly. We use PayPal's API so we don't handle CC details internally (Thank God!)
    – nino
    Commented Oct 9, 2020 at 12:54
  • Oh, and Data is dumped twice daily on the server and twice daily to my local system. I can, and have, restored a students records many times after he has in a temper tantrum deleted them. He has a very very short fuse?
    – nino
    Commented Oct 9, 2020 at 12:54
  • From the sound of this you've tried just about everything. I sympathise with that. The best you can do is define the boundaries you are comfortable with and bear with it. Or ditch this and gamble on using that time for more productive/satisfying enterprise elsewhere.
    – Kain0_0
    Commented Oct 11, 2020 at 23:57

I very much sympathize with the frustrations you're experiencing. Your experience is by no means unique, and it's the general bane of IT staff (not just developers) everywhere.

That being said, based on how you describe the nature of you working for them, I infer that they've paid you for the work but they own the application (and source code) itself. If that is indeed the case, then they are free to do with the application what they want.

It is no different from me hiring a painter to paint my walls, only to then have me shoddily paste some wallpaper over it. If I own the wall, I get to do with it what I want.


...if the client's actions impact your work, you can address this point. How it impacts you depends on the nature of your agreement.

  • If you are expected to support the application and the customer's changes keep causing you to have to spend more time fixing it without getting paid for that time, then the customer's actions are affecting you.
  • If you get paid for that additional support effort (i.e. billed hours), then you're not being unreasonable affected. If anything, that's just giving you more billable hours.
  • If you are hosting the application, and the customer's changes unreasonably impact your hosting environment, that is a problem you can address with them.
  • If the customer airs a public review about you and the quality of your work, and includes the consequences of their mistakes, that's something you can address, as it unfairly impacts your reputation for something you did not cause.
  • If the customer refuses to honor the full deal because of "quality issues" with the product, this needs to be addressed.
  • If the customer's changes happen during development, and needing to fix the issues keeps you occupied and endangers you delivering the project by the agreed upon deadline, then you have to address this with the customer. Either they stop fiddling with the application and causing you extra delays, or they explicitly (get it in writing!) agree to postpone the deadline based on any delays you may encounter.

The bottom line here is that the only real leg to stand on here is if the customer's changes directly impact your bottom line, without being compensated for it (e.g. billed hours).

But you haven't mentioned any of that in your question. All you've mentioned is how you think the customer's changes are not great and could be done better. That's all fine and dandy, but you don't actually get to force your customer to exclusively touch the source code, if they own it.

That would be equivalent to a local grocery store forcing you to buy your vegetables from them based solely on their claim that the vegetables they sell are better than the ones you grow in your own garden. Regardless of whether that's correct or not, it's not a basis for forcing you to buy vegetables from them.

Part of being a software development consultant/employee is learning to let go of your baby. You don't own the application, and you can't prevent it from being altered if you don't own it.

It sucks to see an elegant system get diminished by an inexperienced developer. In my native language, we have an idiom for this: a gorilla in a porcelain cupboard. I very much sympathize with your feelings about the situation, but you can't really change this.

At best, you can try and ensure that you retain ownership of the source code in your next project, so that you can retain executive control over its development.

  • Thank you also for your thoughtful response. Who does on the code? That is a good question. I've spent years as a creative professional and kept copywrite notices front and center. Same here. I have a copywrite at the bottom of the footer with a link to my site and on every code file. You are right too though, it's his business and if he wants to do thing the way he wants, well who and I to say differently. let go of your baby - had to do but point taken.
    – nino
    Commented Oct 9, 2020 at 13:02

You don't do anything, until the client has screwed up the system irreparably. You were paid to develop and maintain the system, and you have been cut out from that.

When the system is inevitably broken beyond the client's ability to fix, you push your last version from source.

It sounds like the system you built was reliable, but not flexible. Take this as a lesson going forward, and look to provide runtime hooks to change behavior.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.