Because of the nature of what I do, I often get asked to look over other people’s work. This isn’t always under ideal conditions. Sometimes a company hired a freelancer or employee to do a job but they are unhappy with their progress. I always feel bad for these companies because if they came to me first, I could have saved them a lot of trouble and hardship. To save everyone’s time in the future, I’m listing the two most important things you should arrange before you work with someone to build your software:
Always get access and ownership to the source code of the product
The worst thing that can happen is you pay someone to build your software and then have no access to it. If you work with someone they may do this because it slipped their mind, or it may be for more nefarious reasons: If the original writer has control over the source code, that means you have to work with them to make changes. That’s an unethical way to guarantee repeat business. But, what if they’re too busy to help you right now or their hard drive crashes and they lose all the code? This could literally destroy your business. For these reasons it’s essential that you have access and ownership of the source code that they write.
I know a lot of people reading this aren’t technically minded and may not be sure whether or not they have access and ownership. You should feel comfortable that you could hire someone else in the future to add a new feature to your product. If you’re not confident of that, you should have a conversation about this with the person building your software before they write a single line of code.
If they do not make you feel confident on this detail, you should not work with them. The risk is not worth the reward. They would have the power to hold your code hostage and charge you an exorbitant amount of money to fix bugs or add features in the future. Without access and ownership of the source code, your only options are to pay them or start the whole project over from scratch.
Get a list of usernames, passwords and servers that the code is deployed on
Allow me to use an analogy to explain the difference between these two tips. Imagine you’re writing a blog article. You want the ability to edit a draft and then when it’s ready, you want to be able to publish your work. The tip about “access and ownership” gives you the ability to edit your software like a draft. But, until you publish your work, nobody will be able to see the changes. This tip is about being able to hire a different person to publish the work on your behalf. To do this, the person you work with next needs to know where the software is deployed and how to login to the server it’s hosted on.
Depending on what you’re building, the list of usernames, passwords and servers may be very long. For example, a project may use a lot of 3rd party services, databases, etc. If you want to make public facing changes to any of your software, you need to know all of this information so you can hand it off to someone else in the future. Even if you think you’ll be working with your current contractors/employees forever, you should still do this and they should still give you this information. It is unprofessional not to.
Conclusion
When a new company works with someone to build their software for the first time, these are the two biggest mistakes they make. Unfortunately, this happens all too often. I hope by reading this article you can avoid this problem in the future. If you can think of other mistakes that are worse than this, I’d love to hear from you.