Mobile and Tablet Marketing, Search Marketing, Technology

Avoid getting taken Hostage by your Developers

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:

  1. 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.

  2. 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.

  3. 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!

  4. 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.

6 Comments

  1. 1

    I’m a web app developer and I agree with most of your points (perhaps all) but I’d like a clarification on #3.

    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?

    • 2

      Notreally,

      I think we agree. My point in this is to ensure that you have the code and can walk out the door with it. If your developer is compiling code for you and pushing it out to your site – you don’t have the code. I’ve seen this happen with everything from graphics, Flash, .NET, Java… anything that requires a source file and is outputted.

      Doug

  2. 3

    I see where you’re coming from and while I don’t agree with everything 100% (I have caveats), companies should always keep this in mind.

    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.

  3. 4

    Nice post… well done although I disagree with one item (#2):

    “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

    • 5

      Hi Michael,

      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.

  4. 6

    I’m also a web app developer, and I think you’ve hit the nail on the head. Some thoughts:

    I think most everyone would agree (and has based on the comments below) #1 is a absolute. Never, ever do it. Ever. Under any circumstance.

    I have a different take on #2 than perhaps some of my fellow developers: we refuse to host the final product for our customers (of course, we host a testing server for clients to test drive the product during development). We’re happy to help clients get set up to host it themselves or find a hosting provider. We simply don’t want to get in the business of hosting. If that means turning work away, so be it. There are lots of great hosting companies or infrastructure firms out there than can provide this service at a much cheaper price. We encourage the portability of our work, and will do whatever we can to assist getting it hosted, even if the client switches hosting providers years down the road.

    For #3, our clients get all the source code of the final product with one caveat: For third party products that are used in the solution (such as web controls from Telerik or Component One), we can give the client the compiled dll for the third party control (say a grid). Our licensing agreements with those third party companies (which we provide to the client) prohibit us from redistributing the source code for those type of controls, because it is the third parties’ intellectual property, not ours. The use of these types of products saves development time for the client and is much cheaper than building the same functionality from scratch. We are upfront about this policy before any work is done. Of course, if the client wishes to pay for custom control development (instead of using the prebuilt product from the third party) we provide the source code for that custom control along with everything else.

    When it comes to code reuse, we are upfront about the fact that we may reuse portions of the code unless it was expressly developed exclusively for the client’s use (say for a proprietary business process) before any work is done. If the client wants to have exclusive code developed of course, that is available to them.

    As others have said, #4 is always recommended. Always!

    Regards,
    Tim Young

Leave a Reply