Avoid getting taken Hostage by your Developers
Douglas Karr
This weekend I started up a conversation with a local artist who has been assisting her boss with the management of a couple of web applications her boss owns.
The conversation took a turn and some venting went on about paying weekly development fees without seeing any progress with the developer they’ve been working with. Now the developer wants to charge them another lump sum fee to complete the project as well as a weekly maintenance fee to cover other requests. It gets worse.
The developer transferred the domain names so he could manage them. The developer also hosts the application on his hosting account. In short, the developer is now holding them hostage.
Thankfully, the woman I’m working with demanded administrative access in the past to edit some of the template files for the site. The developer could have provided her limited access but he didn’t. He (lazily) provided her with the administrative login to the site. Tonight I used that access to backup all of the code for the site. I also figured out what management software he was using and made my way to the database administration where I was able to export both applications’ data and table structures. Whew.
The owner was planning on moving the sites to new domain names once development was completed. That’s huge because it means the current domains could expire in the event that there’s an angry separation between the developer and the company. I’ve seen this happen before.
Some tips if you’re going to get an outsourced development team:
-
Domain Registration
Register your domain names in your company’s name. It’s not bad to have your developer as a Technical Contact on the account, but never transfer ownership of the domain to anyone outside your company.
-
Hosting your Application or Site
It’s great that your developer might have a hosting company and can host your site for you, but don’t do it. Instead, ask his recommendations for where to host the application. It is true that developers get acquainted with the management software, versions, and location of resources and that can help your product be completed sooner. That said, though, own the hosting account and add your developer with his own login and access. This way, you can pull the plug whenever you need to.
-
Own the Code
Don’t assume that you own the code, put it in writing. If you don’t want your developer using the solutions you paid him/her to develop elsewhere, you must decide that at the time of the contract. I’ve developed solutions this way but I’ve also developed them where I retain rights to the code. In the latter case, I negotiated the cost of the application lower so that there was an incentive to the company to give me rights. If you don’t mind your developer using your code elsewhere, then you shouldn’t be paying top dollar!
-
Get a second opinion!
It doesn’t hurt my feelings when folks tell me they’re taking bids or consulting with other professionals. In fact, I recommend it!
The bottom line is that you’re paying for your developer’s talent but you must retain control and ownership over the idea. It’s yours. It was you who invested in it, you who risked your business and profitability for it… and it’s you who should keep it. Developers can be replaced and that should never put your application, or worse - your business, at risk.
Wholesale duplication of a site or application sold to another company (or worse a competitor) is unethical and should always be stipulated as not acceptable in your contract. However, I have developed innovative solutions to common problems while working on a client’s project that has nothing to do with their particular biz nor does it represent a significant portion of the overall solution.
Example:
Client wanted page level and field level control tied to user roles. The “out of the box” functionality for ASP.Net does folder level permissions. So I extended the native permissions for .Net and delivered the solution as part of an overall web appplication.
I believe that they are entitled to the entire codebase (as stipulated in the contract) but I feel justified in using the same methodology and chunks of code to accomplish this extension on future projects.
Another wrinkle:
I did this while being farmed out by a consulting company. Would the consulting company have the right in your opinion to go back and copy that solution, marketing it as their own?
1. ABSOLUTELY. Can’t stress this enough. I’ve worked for a small company that did this and I felt crushing guilt over being involved. I’m so glad I was able to get out of there. Customers should absolutely retain control of their domains. If they have someone savvy enough, don’t give the developer access to this. If not, make sure the developer has a way for you to change info/transfer the domain via a reseller interface of some kind in the very least.
2. I’d partly agree with this but then it depends on the situation. If you’re deploying a simple PHP app and need low cost hosting, by all means, get a LunarPages or DreamHost account or something and dump it there. Give the developer access. However, low-cost shared hosting certainly has it’s drawbacks… especially for bigger things. But if you’re big enough to be worrying about that you should have someone technical on staff that can deal with it. A lot of it is obviously about trust. Sure as hell put something in a contract if you can about this kind of thing (restrictions and such). Third party hosting is great if the developer doesn’t need to do anything fancy. I admit I’m torn because it’s really a situational thing. It also depends on the size of the site, the array of technologies used. If it’s gonna be big, considering hiring a person on staff. Not always an option, but safer for big stuff.
3. This is also something my former company did. You could leave, they would give you the HTML, images etc…. but no code. The code was a leased service basically. That being said, there’s owning and owning. I’ve always done a non-exclusive sale. Basically, I need to be able to reuse my components. I have no issue with the client owning it, doing what they want with it and having someone else work on it down the line… but I ain’t gonna mortgage myself and have to reinvent the wheel every time.
4. Always. Always. Always.
“It’s great that your developer might have a hosting company and can host your site for you, but don’t do it.”
Though I understand the logic behind this, it can be counter-productive in some cases to mandate that your project be hosted somewhere else. If the company developing your site or app has a hosting platform that they prefer to use, chances are it will be more efficient and productive for them to use it.
Additionally, from a philosophical standpoint, if you refuse to utilize your developer’s hosting platform because you don’t want to be “held hostage”, then this sets a tone of distrust from the start. If you really don’t trust your developer enough to host with them, then do you really want to be working with them in the first place?
I know that many horror stories do exist about this sort of situation, but in general I would recommend that you focus on finding a developer that you trust. You can utilize your developer’s hosting and still protect yourself by requesting administrative access and making your own backups.
Again, good post and very useful information.
Thanks!
Michael Reynolds
It may sound like a trust issue but I don’t think it is - it’s really a control and responsibility issue. If you’re going to invest a significant amount in your web site development, then you must be sure that you can control its environment.
Things happen in business that break relationships and they need not be negative. Perhaps your developer/firm gets a very large client and can’t afford you the time. Perhaps they shift business objectives. Sometimes their hosting company can have issues.
I’m advocating that you control and be responsible of your hosting so you can depend on your developer for what he’s great at - developing!
I appreciate the push-back, Michael.