Hey WordPress Developers, Your Clients Should Own Their Plugin Licenses


Before we get into this I want to say that WP Migrate DB Pro doesn’t really apply here. It’s a developer tool so the developer should own the license, not the client. A carpenter should own their own hammer. Our other plugin, WP Offload S3 definitely does apply here though. Ok, now back to the show…

Just the other day I had a tennis match with a local business owner. He was telling me about the ordeal he was going through to get control of his domain name. Once upon a time, he had hired a developer to build his site. The developer had used his own details (including email address) when registering the domain name. And now he couldn’t reach the developer. He tried contacting the registrar but they wouldn’t give him control of the domain name (and rightly so).

I’ve heard similar stories involving WordPress plugins. Client hires developer. Developer adds a paid plugin to the site during development and uses their “Developer” (unlimited sites) license. Developer doesn’t renew their license and the client isn’t able to update the plugin. Worst case scenario: the client never updates the plugin and eventually it breaks the site or the site gets hacked. Best case scenario: the client is angry because they need to buy a new license to update the plugin but they grind their teeth and hit “Complete Order”.

If a paid plugin is integral to the site, the client should be the owner of the plugin license. They should get a bill every year (or however often) for the license renewal and should have to pay that bill to keep the software up-to-date and have access to support.

The main argument I’ve heard against this is that clients aren’t willing to pay for a plugin license. But that sounds like communication failure to me. The client needs to understand that the cost of the plugin license is the cost of the features it brings to the site. What would it cost to develop the features from scratch? And what about all the bugs that come with developing something new? If the features aren’t worth $59 per year for them, then maybe they don’t need them after all? Most clients are fine with paying for a plugin license as long as it’s clearly communicated as part of the proposal at the beginning of the project and the recurring cost is made clear (i.e. there are no surprises).

Of course there will be clients that have an archaic software procurement process. They have to fill out forms and bounce them between half a dozen departments for approval, and oh, did they mention they’re NET 45. Yeesh!

But hey, that’s why you have a “Developer” license. Use it to work on the site but make sure to swap the client’s license in later. And even if you forget to swap it in, at least you’ve set the client’s expectations that this is a license they need and they need to renew annually. If they run into trouble with the plugin in the future, they’ll have a license for the plugin that they own, and access to updates and support; everything they need to resolve the problem.

I know what you’re thinking: “Procurement? This doesn’t sound like my clients, this doesn’t apply to me.” Wrong. You missed the point. This is about expectations. Your clients may not have a procurement process but they definitely do have expectations and if you don’t skillfully manage their expectations you’ll end up with very little repeat business.

So please, next time you take on a new project figure out what paid plugins you’re going to use, put those in your project proposal with first year costs and future annual cost. And be clear about who’s covering the first year cost (you or the client), who will actually purchase the plugins, and what date they are needed by. And even if you are covering the first year cost, please please please replace your billing address and email with the client’s once you’ve completed your purchase. Otherwise they won’t get an email at renewal time.

As a company that sells plugins we could certainly be doing a better job encouraging developers to have their clients own plugin licenses. For example, after purchase we could prompt the customer, “Will you be handling renewals for this license?” and show a form to update the billing contact. Or we could borrow Flywheel’s idea and allow our customers to create a URL to send to their clients to pay for the license themselves. I’ve never used Flywheel hosting but I absolutely love the way they allow their customers to pass on billing to their clients.


While I love the idea and do plan to implement it at some point, it just hasn’t topped our list of priorities yet. For now, our customers have to instruct their clients on how to purchase a license or buy the license themselves, bill their client, and then update the billing information on the account so that the client gets future renewal emails. Far from ideal, but it works ok.

How do you handle plugin licenses for your clients? Do you let them use your “Developer” license or have them buy their own license? What’s your process? Please share in the comments.

About the Author

Brad Touesnard

As founder of Delicious Brains Inc., Brad wears many hats; from coding and design, to marketing and partnerships. Before starting Delicious Brains, Brad was a busy freelance web developer, specializing in front-end development.

  • This has been a question I’ve struggled with for years Brad, and I think you’re spot on. The biggest issue has been getting the client to go through the process of setting up multiple accounts. My goal is to make things as easy for the client as possible so I’ve often just added my own dev license and forgotten about it.

    It’s time I put together a clear strategy for handling plugin licenses. Thanks for the prompt.

  • This is an interesting topic that I don’t see talked about often. I’m anxious to see what other comments pop up here, but here are my thoughts:

    We started offerring managed hosting years ago because there was this uncertainty as to who was responsible for taking care of software updates of a site that was released to a client. The obvious answer is: “Well, the client.” But that turns out to be the worst person to make plugin updates (especially in the 2.X days where updates were happening all the time, and plugins were not really adhering to WP best practices).

    So, I decided to offer managed hosting, via a server we lease with WPEngine, and as part of that plan we maintain all plugins bi-weekly. In this case I think it makes more sense to include plugin licenses into the cost.

    For one, it’s easier. We’re maintaining the sites, and when there are issues with plugins, it really should be me or someone on my team investigating the problem with plugin support. In most cases, I’ve been a long time user of the plugin (I think you mentioned I was number 2 at WP Migrate DB Pro), so I’ve established at least a small bit of rapport with the company.

    Secondly, we can make more money. I’d be lying if I didn’t say there’s a business decision here. We buy the plugins at developer or agency rates, and then we absorb the cost into our monthly managed hosting and maintenance deal.

    Now, when a client does not choose to host with us, we are very upfront about the additional license costs. When a client leaves our hosting, we have an offboarding process that does the same.

    Ultimately, I think this will fall into every other scenario where we start the answer with “It depends”


    • This is exactly what I do. If the offboarding process is clear from the outset with its affiliated costs then it works well.

      What I’ve found frustrating previously is lousy control of which sites are authorized to use my licenses and finding past clients either still using my license key or not having updated in years. It would be nice if the dashboards/accounts of plugins had the ability to change the key or block previous ‘registrations’ of the license. Worst case scenario was a plugin that didn’t obscure the key and so a staff member at the company started using my license on his ‘off-book’ projects.

  • Brenda Malone

    I could not agree with you more! This also applies to themes/frameworks that have an annual subscription. In fact, with the exception of development tools as you mentioned in your opening paragraph, the value of a developer’s license may be great for the developer, but TERRIBLE for the client. The client is totally dependent on a future relationship with the developer in order to maintain their WordPress website. Not a good model.

    In fact, this has happened to me: I built a site for a Client, used my developer’s license for Gravity Forms, Genesis, a child theme from Web Savvy, Ithemes security pro / backup buddy / stash and a couple of others. All was well and good UNTIL the relationship ended. I was left in an ethical quandary about whether to leave my licenses and be permanently tethered to a former client or to just yank the licenses and put the client’s site in jeopardy.

    After that, I no longer even purchase Developer’s licenses and will make the client purchase all things that require licenses (actually I purchase the items and once reimbursed, will change ownership details, so I wish that the transfer of ownership would become more available.).

  • Love the conversation. This is directly applicable to me as I run a WordPress maintenance & hosting service for small businesses. The problem I see most often is that paid WordPress plugins tie their support system in with the billing system. In short the one paying for the plugin is the one required to open a ticket if there is an issue. Due to that structure it’s not in the client’s best interest to buy the plugins as they have no interest or knowledge to own the potential support that comes along with it. They rather someone else, like a developer to handle.

    I like your idea of splitting support roles and billing roles. For now I solve this issue in the reverse by taking over all responsibilities as a service provider. I buy the themes and plugins which get bundle into my maintenance & hosting services. I also own any support issues which might come along with that. It’s easier to provide it as a service. I might be partial as I also believe the best “Managed” hosting you can buy is the one which comes with a WordPress developer between you and the managed hosting service.

    • jamie schmid

      This sounds reasonable, I’m just curious what your process is for clients who want to move their site away from your managed hosting. How do you handle passing on all the necessary information?

      • When possible, I actually do the migration for the clients into whichever hosting platform of their choice. That way I can handle most of the technical parts and assist with license switchover, etc. I supply them with the latest version of the themes/plugins with license keys stripped out. The client is required to repurchase themes/plugins if they’d like to continue to receive updates and support direct the the theme/plugin authors. Since I typically do not charge for the initial theme/plugin purchase (as bundled with my services), the client is technically only purchasing the items for the first time as they leave my maintenances & hosting services.

    • Good points, Austin. When the plugins are licensed with the client’s email, it can be a real pain to interact with tech support, even when you have the passwords. Having the option for separate support and billing contacts would help.

  • GypsyLion

    Very good article and tips. I typically add the plugins to the line-items in my proposals and build the licensing language in there so the clients know it’s their responsibility to keep their plugins up to date. If there are any discrepencies, I try to hammer it out later making sure the clients have access to the assets they own by providing login credentials in their name.

  • I let them use my Developer Licence, sadly, it’s hard enough to explain they have to pay for a hosting service AND to renew it…
    The best way, is to contract an annual paid plan for all those services with the client, like a maintenance deal. I agree with you on the fact that idealy the client should own the plugin licence…for sure.

  • ryandonsullivan

    In my mind there’s never really a scenario where a client shouldn’t have full ownership of their software, for exactly the reasons you’re describing.

    We run a business kind of like a few other folks in the comments here, but we always have the client purchase the software they need to make the site run. Sometimes it’s a little bit of a slow down or a road block on their end, but at the end of the day, it’s not really a negotiation, it’s a requirement. Nothing is going to move ahead without them making the purchase and that piece of functionality will be missing.

    Another thing that I haven’t seen anyone mention yet, is the “what if I get hit by a bus” angle. The reality is that individuals leave agencies, and agencies themselves can be fleeting, so tying a critical piece of your client’s website to your own company, knowing that there’s a potential you won’t be in existence for as long as they will (hopefully that’s not the case but always plan for worse case), then it’s pretty selfish to use your dev licenses on client sites.

    We even go as far as to roll that into our monthly site audit process. We verify license keys and vendors so that if one of our keys did somehow end up on a client site, we can give them instructions for making the necessary purchase, and also ensures that pirated software isn’t being used.

    • alex vasquez


  • dsgreen

    There is an argument to be made for the developer purchasing the plugins as part of the project. If the client is paying a fee for a custom site, and possibly hosting and maintenance, the transaction is a bit smoother if it’s all bundled together in one fee. The client wants you to solve a particular problem, and itemizing plugin fees seems a bit like an auto repair shop itemizing parts and labor. In my experience, the client doesn’t care what plugin you’re using. It’s only if there is a change in the developer in the future that this could become an issue, as the post indicates. If I take over a site and the developer is out of contact, I license any expired plugins myself. It saves the client hassle, and you take care of all the details for the client.

  • richoid

    I philosophically agree, but about half of my clients are just too confused by all the details. They are small business people with too much to think about and no dedicated staff or even a marketing director to think things through. So, I keep a dev license where I can, and often buy licenses for clients on other plugins/themes simply so they don’t have to stress about it, if they have that problem. I might have a line-item in the bill if it’s over ~$50. About 1/2 are sufficiently savvy to manage their own licenses. The other half can’t even keep track of their logins. I always am rooting for the developers, seeing they get paid, trying to do things ‘right’ but in the real world, I’m often lucky if my client reads past the subject line in the emails I send. Long lists of decisions about things they don’t understand drive them nuts. I feel like a therapist as much as a web developer. But I also only take clients I personally like, so that’s OK. It’s part of the job that I weirdly actually enjoy; making their lives easier and smoothing out the complications for them. It’s a trade-off. It’s all good.

  • Love this post. This is exactly what I was trying to tackle with my article about the plugin market a few years ago. I’ve never really had an issues selling my clients on the need for plugins, but this is an area that gets sticky pretty quick.

    I fully agree that the clients should own their licences. One of the primary reasons I choose to develop on WordPress is that I never want my clients to feel like they are stuck with me. I want them to have a robust developer ecosystem and choose to work with me, not be forced to. What a lot of clients don’t understand is their website is an asset to their company, a great website should add value to your company’s bottom line and as with any asset there are costs associated with operation.

    The primary problem for me is that we don’t have a good way of achieving this at the moment. I do host some client sites with flywheel and its an incredible way to do things, for a single transaction. Where things get tricky is when your using something like WooCommece and can have 25 different plugins for 4-5 vendors. I’ve had clients think there was fraudulent activity on their card and open cases with their credit card company over plugin renewals. It’s cumbersome for us creators to understand the ins and outs of the plugin market, and even more so for our clients.

    With this in mind I still feel that some sort of unified premium plugin management API is the way to go. Personally I would love to see things like:

    – A clear division of free and paid plugins in the admin with a renewal date column
    – Domain based licencing (death to client facing keys)
    – Wont happen, but a unified payment system with the option to sync licence renewals

    We will get there but I feel like an effective tool will have to have API’s included in core and open to all. Not sure that will happen anytime soon.

  • RoughDraft

    I agree completely. I used to work at a company in which a vendor built a site for us. It was supposed to be in WordPress, but they used Expression Engine. Beyond that they used a custom font with a one-year license. We did not know about this and when the license expired the site went to hell. It looked like a BAD 1995 site. The vendor was long gone. We knew nothing about Expression Engine, I’d never dealt with custom fonts (I’m old school, I want my fonts to work in any browser for all time). I will never recommend that vendor to anyone.

    At this point I’m on my own building sites for people I care about. I do own all the domains and plugins, but that’s because I pay for them myself and maintain them myself and these are such small businesses that do good in the world. I build their sites and host them and if I die the clients and the information they need are listed in such a way they could recover everything BEFORE there’s a problem. You always have to think of the hit-by-a-bus issue.

  • kronda

    Great post! This has long been a pet peeve of mine as well, so much so that I wrote http://karveldigital.com/business-owners-digital-assets I’m a big fan of clients owning their plugins. And if I’m going to use my developer license there’s a clear discussion around it and I make them aware that if they decided to part ways, they’ll need to purchase the licenses. I changed my whole business to only work with long term clients so this is less of an issue but awareness and expectations are key. I also document my client’s sites including a spreadsheet of all the plugins, free or paid, who owns the licenses, and the renewal dates.

    Thanks for posting this.

    P.S. Flywheel is awesome.

  • Chris Miller

    License management is a huge hassle in general. Unless a customer is paying us on a service contract, the annual renewal is just a time sync and financial loss for us. What little you could charge as a licensing fee is eaten up by administrative overhead. We will create accounts at the plugin vendor on our customer’s behalf and pay the initial fee which we pass through at cost to our client. At the end of the project we simply change the email address to the customer and they can manage renewal from there. If they need assistance installing any license keys, the conversation changes to a billable support task instead of an unpaid burden.


    Chris Miller
    President – Rocket Scientist
    Launch Brigade
    (831) 480-7190

  • For plugins like ACF or flickity, I buy the client one and attach it to their admin@their-site.com email address (and expense it). They wont even know it exists, but the next developer will find the info in a README. For WP-migrate-pro it’s not so easy. I don’t think I can talk them into paying for a tool that is really only for me. When I must work on a WP site, I’ll need a local setup / a staging setup / and a live setup. They often have a running site that needs to stay in place until we launch. The client can start putting in their content on the stage… then I pull data down, and push code up. Then when we launch – the data gets sent to the live site, and the client only inputs data there – for the rest of the site’s life. The only time I need the plugin from here on out, is when I need to pull the database down to my local machine or to pull it down to the stage. In this case, I may only use migrate-database-pro for 3 minutes a year ~ for each client. If it was $30 a year, I’d have my clients pay for it – or roll it into the expenses, but as of now – I just have the one – and in most cases, I can just detach it when the site goes live.

    The main problem with getting the clients to pay for things, is that they don’t know how to. Anything from a gmail account – to google apps – to hosting – to domains – to plugins / it’s a different mess depending on their level. One-off small clients don’t want to give you their credit card number ~ and don’t want to do it themselves… there definitely needs to be a better handoff technique for all of these things.

  • A. Canton

    We go out of our way to use non-premium (i.e. no cost) plugins… or we write the functionality ourselves, if possible. For some themes and a few plugins we have a lifetime development license (i.e. Studio Press… which I don’t think has lifetime licenses anymore.)

    Clients don’t like software licenses in general, they don’t understand them, and are afraid that the vendor of some core functionality will one day jack up the price and basically hold them (the client) hostage for what amounts to a ransom payment.

    Our clients don’t want to have 10 to 15 accounts with 10 to 15 different vendors billing them at different times of the year for something they (the client) does not quite understand.

    When we do have to use a premium plugin we make the client go online and buy it themselves and send us the auth-code or whatever is needed to activate it.

    What we’d like to see is a clearinghouse where the client ‘registers’ all their plugins and themes, they get one bill from the clearinghouse, they write one check, and the clearinghouse takes its cut and sends the rest off to the various developers. I don’t know how developers would feel about giving up a percentage of the fee to such an entity but if there were such an entity we’d only recommend products to clients from developers who used it. I’m surprised that Envato and similar retail outlets do not offer this kind of service.

    • ItchyBrains

      I like the clearing-house concept too. It would help reduce other issues, such as piracy. I know from my own experiences, the confusion surrounding free-or-paid software, and then further payments required for updates and services, has become simple to understand, to clients it seems really hard to grapple, as they don’t really have other areas of their life where the equivalent takes place. A clearing-house model might really help.

  • Vayu Robins

    Good points! However I would like to read the comment but the font size is way too small on my iPhone. 😉

  • great topic and is something that i have grappled with as well (as i run a similar type of business model to other folks here). as to what the solution is i guess that depends on context of the client and your relationship with them and what type of service you are providing.

    there are so many aspects of to this discussion as have already been mentioned.

    i personally agree in theory that yes the client should own their own licenses… however in practice it almost never works out like that, like said alot of clients barely know how to log into their own site, let alone manage plugin updates.

    with this in mind it’s a lot _ easier_ to roll the cost of your dev license key into the maintenance fee. because at the end of the day a lot of clients simply want to know the site is up, secure and running. and would rather work with one vendor than have to work with numerous others.

    however there is another model as well, and it’s something i’ve also considered – and that’s plugin license rental: the logic is that you rent your dev license key to the client on a monthly / yearly basis. of course the total amount you rent the key out for would have to be less than what they would have to pay for a license renewal.

    as long as you are upfront with the client about the costing structures, then generally there shouldn’t be too many hassles.

    another thing which is related to this and to consider is would be what would the point be of investing in a dev license if you as the wordpress developer can’t profit from it?

    take gravity forms… a dev license is a lot of money and the yearly renewal as well (of course there are additional features to incentivise you to buy that dev key) but my point is this… what is the point of having unlimited sites… if you not going to use that key over and over

    • In the case of Gravity Forms, the point of the unlimited sites license is that you have more than 3 sites. Personal is 1 site, Business is 3 sites, and Developer is unlimited sites. If you have more than 3 sites, you need Developer. They could just as easily call the Developer license “4 sites or more” rather than “Unlimited”. The latter is just better marketing.

      • completely agree assuming you only manage 3 sites…

        if, however, you are managing more than 4 sites as a developer, and you’ve invested in that functionality / feature set to be able to offer a client that feature set, what is wrong with you making a margin on that investment by using the license key as often as possible to enable that margin?

        after thinking about this a bit more i reckon this comes down more to your business model.

        if you are a developer that hands complete control over to the client after the build then it makes sense to also make sure they have the control of their asset, as you’ve costed the entire build… but if you’re more skewed towards a hosting / maintenance / after sales retainer / subscription type service… it probably makes sense to re-use that license key to maximise ROI on the investment simply because you’re upfront cost is probably a lot less because you know you will be making it up in the long term on the lifetime value of the client.

  • Most of what I think has been said by Michael and Austin with whom I find myself in full agreement.

    IMO the future is managed hosting, or managed everything…

    I am happy to build in the dns, theme, images plugin costs up front, but as we will be handling the support we need some sort of break when buying a plugin or theme. Unlimited developer licences cover some of this but as you say Brad sometimes it’s not always appropriate.

    One way to achieve this might be to have incremental cost for a new hosting service licence. That is, we pay a minimum yearly fee plus some smaller amount per site. I think this is fair because the more sites we have the more we know your plugin and the less tickets you will get… and when you get them they are more likely to properly document an issue.

    As Michael said, there are probably myriad use cases…

  • This has been on my mind lately as well and I really appreciate hearing everyone’s thoughts and experiences. I’ve been building websites since 1995 and maintain sites for about 40 clients. Most of the sites have been created in or migrated to WordPress. I have several developer licenses (Gravity Forms, ACF, WP Simple Pay Pro for Stripe, Advanced Post Types Order, and of course WP Migrate DB Pro) and font service with Fonts.com. I use ManageWP’s service to manage the sites, keeping them clean and up-to-date.

    I use my developer licenses on any of my sites that need them. As others have mentioned, most of my clients are challenged even to renew their domain names on time each year. Using developer licenses saves me a lot of overhead vs keeping track of
    licenses for each site. And some, like Gravity Forms, tie priority
    support and some of their add-ons to the developer license. So I just fold the plugin cost into their maintenance plans. If clients need premium plugins that I don’t have licenses for, I encourage them to purchase the plugins themselves but most prefer for me to do it and then bill them.

    I recently added the following paragraph to my contract boilerplate:
    “Software Licensing: We have developer licenses for several commercial services and plugins that we will be using on your site, including but not limited to custom font delivery, Stripe payment processing, and custom web forms. We fully expect to continue renewing our developer licenses for the foreseeable future, but we reserve the right to discontinue if we are no longer using or recommending them, or if circumstances change. At that time, you may need to purchase individual licenses for these plugins or services. The total cost for individual licenses is estimated at $150-300/year. Please let us know if you would like details.”

    Unfortunately I don’t see this as sufficient. I provide each client with password-protected “tech specs” for their sites that include all the credentials I have for domain registration, hosting, and other services. This article has convinced me that I need to add information about plugins. Then again, I can’t count the number of times people have lost their tech specs or forgotten the password for them. Anyone have suggestions for training clients?

  • Leo

    Thanks Brad. It becomes harder in Asian countries where the currencies are weaker. Over here, I even have friends in agencies balk at purchasing premium plugins for their clients.

    Rather, some asked me for my developer licenses to use with their clients’ sites. Sigh.

  • Spencer Forman

    We teach freelancers that plugin licensing is an “Upsell” opportunity for more profit. If you are doing things correctly, the client should come to rely upon you as their “guru” and doesn’t WANT to know what you “put into the soup”. As such, it is a far better thing for them, and a far more profitable thing for you, to merely inform that that there is an annual fee (or amortize it monthly if you prefer) to keep the site running, including all the special plugins, services or software required.

    We’ve yet to find any client who does not appreciate this simplicity… much in the same way anyone appreciates being charged ONE amount for the bowl of soup you just ordered in a restaurant, rather than being informed that you’ll need to contact the chicken farmer, the carrot farmer, the salt harvester, etc., to pay for your soup on your own.

    In simplest terms…the client wants YOU to solve THEIR pain, and to give them ONE cost for doing it all…not take on the task themselves..

    Our 2cents….

  • 2urn

    As part of my proposal and contracting with clients I always explain that variety of premium tools (plugins, themes, saas) will be used to add functionality to their site and that these tools have to be licensed and that some even have different tiers of licensing, such as Gravity Forms, that affect what functionality is available. My contracts usually include a year of maintenance during which I handle all updates and license renewals by way of my developer licenses—as long as they renew their maintenance/support agreement I continue using my licenses.

    There are two exceptions: plugins that do not have a multi-key developer license (many on Envato are this way, for example) and plugins that I don’t use routinely enough to warrant my maintaining of a developer license. For these I have the client buy the plugin directly and give me login access to the developer’s support site when necessary.

    In all cases the clients are provided with a list of premium dependencies and associated costs and can replace my license with their own at any time. So, if the maintenance relationship ends I don’t feel any additional responsibility to protect them from themselves. This has worked so far without any stress or loss of sleep.

  • A while ago I bookmarked this for later reading and commenting.

    I agree with you that a client should be the owner of his URL, website and other assets. But in real life there are a few thing to consider:

    For the URL, the hosting provider and content of the site I agree. But for the engine of the website I don’t.

    Most plugins do have a developers licensing system. This makes it possible to add it to a site and earn something back. Price-wise this is cheaper for me and the customer and for the rest: as long as I am responsible for the proper functioning of the site, all plugins should be updated regularly and I take care of that.
    While keeping the plugins under one license is easier for me to keep everything up to date. Since I have 50 or so WP websites running for my clients, keeping track of 50 separate licences for Gravity Forms is just work, like billing and building. Sharing my license is the easiest and most transparent way of earning a bit for this work.

    The only what-if in this model is that there is the need for an agreement in which is arranged that when you hand over the site to another developer or to the client, these licences will be removed. For many plugins this means that there is no option for updating or upgrading or support but they still work and the site is not broken in any way. If the client wants to keep the support and updates he has to buy his own licenses. And that is exactly what I’m offering: the sites I build are build with dev licenses, if you want to leave me – no problem but you have to buy your own licences or find another solution. That is all clear before I do anything for a clients website.

    On the other side: I some clients moved their site to me for further development. Being confronted with not updated plugins, plugins I don’t want to use, plug-ins that are changed by the developer and are broken when updating – I’ve seen it all and the client usually don’t know what password was used, what email was used, what creditcard was used (I think my ex-wife’s…) and I was even confronted with a ripped theme. Making the client responsible for all this did not help me to get everything right in a few hours. The client himself was also lost-in-space because he was quite unaware the site’s well being was his responsibility.