So you’ve decided to go out on your own and start a business as a software developer. Is that a good thing? Do you have sufficient experience to know if this is a good idea, or are you going to see how it goes for a while.
There’s a lot to learn, and this note might help you to think about some of the issues that are in front of you.
Issues for sole software developers and their code
Is your business model dependent on you retaining any of your own code (whether for tools or creating external code on servers etc?). e.g. Have you developed an ‘engine’ to enable you to efficiently deliver your services, which is therefore a core asset of your business?
Who owns the code, and is some or any of it going to be available to you for future work?
Is the code owned by you, the client or is it going to be open-sourced with a license? These are important business and risk questions. If the client can modify the code, who is responsible for the whole system? Be very specific about what your product is.
Whenever you discuss code, think about your intellectual property, and what you have invested in your ideas. Does your code give you a market advantage and if so, for how long? Do you rely on your ability to keep ahead of the market or on a specific advantage from specific code? Do you just sell code to clients as they require it, and so your business relies mainly on your personal coding skill?
If you are not yet in a business arrangement, make sure you think about whether you need to protect your intellectual property (if it is already valuable), or if you are prepared to discuss your information with someone under the protection of a confidentiality agreement.
Remember it is hard to stop the flow of ideas, so make a decision about what you want to share and what you don’t want to.
Research and innovation – special considerations for sole coders
If you are involved in innovation or start-ups, you may have protected environments or ‘experiments’ where you try something out, knowing that it is not intended to have the same risk or legal liability as the main product.
Have your developed a unique software solution that is essential to your business and is capable of registration or needs careful non-disclosure?
How soon do you need to protect your research, if you are offering a specific product to the public or world at large? Are there designs or copyright?
If clients are involved in giving you feedback on a new product, make sure that you think about how much you need to protect your commercially-sensitive ideas, when you obtain their feedback. If this is before you MVP (minimum viable product), make sure you think about protecting the market-valuable information. You may want to think about what you are prepare to disclose in your ‘pitch’ before you enter into a contract.
What is your business and research worth to you? How would your record the value of your R&D time, and your product, before there is a defined product? Are there any financial or tax incentives for recording R&D time as an asset? Seek financial advice on those possibilities.
If you enjoy working with ‘open-source’ projects, then make sure you still have an appropriate open-source licence for your code.
Specific risk assessments for individual contracts
You will need to fine tune your financial model and risk assessments for individual contracts. This will depend on who the client is, and what they want.
In what environment is your code etc going to be working? Will you promise (i.e. offer a warranty) that it will work on a particular hardware, platform etc? Or maybe you won’t. Maybe you want the client to test it, sign off and then they have full risk?
How significant is the code to the client’s business? It is essential you have an understanding of how critical this is. If you pay attention to this, it will help you weigh up whether the quality and continuity of the code (including maintenance) required is balanced by your remuneration for the work. Is it possible to pass over the risk for the contract working after the end date of the contract, or within a period in which ‘completion’ is assessed?
A related question is what objective standards does the code have to meet even before you get paid? Remember that unit tests or performance tests are only one way of getting sign off. The best way for you and client to say ‘this is done, and we are happy’ is up to you. It depends on the nature of the job. Above all, get those specs in writing.