How to keep control of your software business

As a non-technical entrepreneur, you may be tempted to rely on hired help to not only build your software, but also to set up the necessary infrastructure to build and operate it. That approach comes with a substantial risk of losing control of your business, either by malice (e.g. a disgruntled contractor) or accident (the proverbial hit-by-a-bus scenario).

To avoid being at the mercy of other people and circumstances beyond your control, follow these best practices and sleep a little easier at night.

Use company emails everywhere

One good practice that goes a long way to protecting you against losing access to critical resources by accident (your developer gets hit by a bus) or malicious intent (your contractor holds your servers hostage for higher fees) is to make sure that all the various accounts of your technical infrastructure use emails addresses of a domain that you control.

For employees, that is usually a given. But there’s nothing preventing you from giving your contractors an email address with your business domain as well. They can choose to use that email account directly or forward it to their own business email.

The point is that, because you control the email domain, you can at any time redirect the email traffic to yourself, thereby gaining control over password reset features for all cloud accounts and avoid being locked out of service that you pay for and that run your business.

If the service in question allows any account to change their own email address, this can obviously be circumvented, so vigilance is still required. Many of the more mission-critical cloud services do not allow a change of email address for exactly this reason. It pays to know.

Use a password manager

For some accounts, it is unavoidable that you share your account credentials with other people, especially if a service does not support multi-user accounts. In this case, it is imperative that your password is not only unique, but also secure (read: long and random) and not based on any discernible pattern that would make it easier to guess your password for other accounts.

This is only a particularly obvious case of the more general problem of insecure passwords and password re-use1.

There’s a very simple solution for this problem: Use a password manager, and use it for everything2. If you ever have an account compromised because you recycled your password, used one with fewer than 20 or so characters, or followed some cl3v3r p@tt3rn, you really have no excuse in this day and age of widely available, secure and user-friendly password managers.

Domain registration

Never, ever let anyone other than yourself control your domain name registration, either by registering domains on your behalf, or by sharing your domain registrar login credentials.

Changing the settings of your domain is one of the fastest and easiest way to disable your web application or even hijack your domain name. Transferring ownership takes only a few clicks, and once it’s gone, it’s really gone. Just google “domain theft” for some interesting horror stories.

A developer or sysadmin helping you launch or operate your web application may have to make legitimate and necessary changes to your domain name service (DNS) settings. If you don’t have the technical confidence to make those changes yourself, open a support ticket with your registrar and have them make the changes for you (perhaps asking them to sanity check the data for good measure).

Source Control

Your source code3 is yours, or should be according to your contracts and other business agreements. It should be accessible to you at all times on a cloud service such as Github4 or Bitbucket5.

If a developer creates your initial source code repositories, they should give you primary ownership of the account. Ideally, you create the account yourself and invite your developers as collaborators or team members with write access, but without the admin access required to delete repositories. This protects you against both accidentally losing access through the proverbial hit-by-the-bus scenario, but also against more malicious deletion of code by a disgruntled contractor.

If your developer doesn’t use source control, or only on their local machine, fire them. Seriously, just fire them now6. There’s absolutely no excuse for that, and it will bite you eventually, up to the point of costing you your business.

Hosting Providers

The same rules apply to your hosting provider, both for your business website as well as your web application (they might not be the same). It gets a bit trickier here to prevent malicious activity, since your developers will likely require the kind of direct machine access that is not easily revoked by a click of a button.

But as much as you can, you should create any accounts with cloud-based hosting providers such as Amazon Web Services yourself, and invite your developers with just the access rights they need. This can be complicated to the point of utter confusion, so don’t shy away from opening support tickets and asking for help. You’re paying good money for these services. And being familiar with the quality and responsiveness of their support before you need it in an emergency is a nice side benefit.

Third Party Services

For most other third party systems, from your own website content management system like Wordpress to your payment provider gateway, the same general rules apply. Depending on the sophistication on their access control, your best choice is to create your own accounts and invite collaborators with just the access rights they need. Most importantly, they should not have the ability to change your own access rights, or to change the primary email address of the account.

If the service does not provide any distinction between administrative and lesser access, first of all, consider alternatives that do. If none can be found, at the very least, ensure that you invite only email addresses of your own business.

  1. Here’s a good write-up of the dangers or re-using passwords across different websites. 

  2. My personal preference is 1Password. See for example here for a roundup of alternatives. 

  3. The stuff your developers write all day, which is ultimately translated into machine instructions that computers such as web servers or smartphones can execute. See for example 



  6. More accurately, the second you’ve received the source code in some form, for example as a ZIP file or other kind of archive. Ultimately, source code is just a collection of plain text and perhaps some image files, and not difficult to share. 

Back to home page