Blog
Web Application Development Blog @ Armia Systems, Inc

How To Safeguard Your Company When Firing An Existing Developer

Posted by: Beth George | On: 29th Jul, 2019 | web development

you are fired textHere’s an industry secret – some technology projects fail. There’s a number of reasons that this can happen but this article is about what to do after it happens.

When you’ve put time and energy into a project that doesn’t work it can feel like the whole company will go down with it. This doesn’t have to be the case. There are a number of important steps that you should take to protect your company and hopefully to relaunch the project later on. 

Ask Yourself, “Is The Project Worth Revisiting?”

The first thing that you should do is ask yourself why you launched the project. Sometimes you see an issue and launch a project to fix it. The problem is then resolved in some other way or you realize it wasn’t that big a problem anyway. If that is the case this time, you can’t get your money back but you probably haven’t lost anything else.

On the other hand, maybe the problem does still exist. Maybe it is still a pretty problem that you want solved. In that case, keep reading. There are some steps that you should take to make sure that you can try again later.

If you’re reading this, hopefully you haven’t fired anyone yet. Don’t. At least, not until you have everything that you need to try to relaunch the project in the future.

Make Sure Own Your Domain

The most important thing might be the domain. If you have been with the developer since day one, they might be the actual owners of your domain. Breaking things off with them could mean that they don’t sign it over to you. Domains can be hard to reclaim if this happens. That can mean restarting from square one. Be sure that your company owns its domain before you fire the developers. This is especially true if you have outsourced the software development to outside developers.

Make Sure You Have The Codebase

Another one of the most important things to have before firing the developers is the Codebase. If you the project was a website, you probably saw the source code. Hopefully you saved it and still have it. If the project was a mobile app, it’s possible that you never even saw the source code. The developers will still have it. If you don’t have it, make sure you get it from them before you let them go.

This is really only the case if you made a lot of progress, or if you hope to work with the same developers again in the future. Developers don’t like working with other developers’ code. If you made a lot of progress it’s worth putting them through it. Otherwise, you should probably just start over next time.

Try To Recover The Road Map

You should also make sure that you have the roadmap and as much progress as possible. Ideally, you have been storing this content in files on your computer. If you haven’t been doing that, hopefully you still have it in the form of emails and attachments. If you deleted anything important, check to see if you can recover it. Some email providers have special “bins behind the trash” that let you recover deleted emails. If you can’t recover the content, try to get as much as possible from the developers before you let them go. 

Try To Get The Source Files

Ideally you will also have the source files. This isn’t code, it’s more like blueprints – actual images of what your webpage was meant to look like. They may have been Adobe files or even hand-drawn sketches. These are usually put together by a usability expert who may have been outsourced by the developers. Getting these back after burning too many bridges with the developers can be a real problem. They can also save a lot of time down the road if you decide to reboot the project. Usability takes a lot of time and money, so it’d be good to hit the ground running next time.

Try To Understand Your Progress

progress graph barsYou should also get an estimate from the developers on how much more work the site needs. This will make it easier to pick up the project later. It will also help you to make decisions about what is worth saving and what isn’t. Development can be a total black box to people who aren’t familiar with it. This means that you might think that the project is a lot farther along than it actually is. That can make it harder for the next team to give you an accurate estimate if you try to revive the project.

Don’t Make Things Harder Than They Have To Be

Finally, try not to totally break things off with the developers if you can help it. Sometimes things go wrong. Sometimes things get ugly. If things go wrong without getting ugly, most developers will continue to help you even if you finish the job with another developer.

That doesn’t mean that you should expect the old developers to keep doing work for you. It just means that if you are professional in letting them go, they will usually work with you and your next development team to make sure that you have all of the files and code that you need.

After all, developers are professionals. As long as you haven’t been too terrible to them and you paid them what you agreed on, they are likely to continue to be helpful and polite. Keep in mind that projects going south is fairly common in business. Even if you haven’t dealt with it before, your developers probably have. After all, they do this for a living. This setback is probably more catastrophic for you than it is for them.

Projects go wrong. The newer and the smaller your company is, the scarier it can be when they do. If you have a good head for record keeping and you haven’t done anything to tick off your developers, it doesn’t have to be the end of the world.

The best advice for saving your progress is to play things by the book and do right by your developers. Your business will recover and when it does you may want to revisit this project. That will be much easier if you have all of your documents in hand and your old developers are still willing to speak with you.

Request a free consultation

LEAVE A COMMENT

-->