In my other article about contract work, I gave general tips on what to watch out for when defining a contract. This article will:
- Discuss intellectual property concerns most of you probably never even thought of
- Give tips on how to build your portfolio if you are just starting out as an aspiring web developer
- Expand on points from the previous article based on the feedback I received
This article is geared heavily toward web developers and will no longer apply as readily to other types of technical contract work. For example, for design related contract work, it is very common and standard that you own no rights to the works you produce (such as a logo) whereas such a point is not always the case in web development. Nevertheless, I tried to keep things generalized so more people can benefit from reading it.
Intellectual Property Concerns
- Before anything else is hammered down, negotiate for joint ownership of the code that you will write. This isn’t always possible depending on your client, but I believe this is worth discussing. If you do not state this up-front, and don’t have a written record of the conversation, you just did work-for-hire, which means you own nothing. I am talking about retaining copyright. They retain ownership of trademarks, trade secrets, or patents they already own that you might leverage during your contract. You’re really only interested in the libraries, not the implementation portions (non-class/function files). Clients won’t – at first – like the sound of this whole “sharing” of rights business, but in reality, it means they can distribute and modify your code any way they please. It affects you because you are able to use snippets or libraries without liability in future projects. If they are not sold at this point, I always point out that the reason I am able to promise them faster development with less buggy code is that I have a well-tested library from past jobs that they will be benefiting from. Frankly, if they still can’t accept the idea of a mutually beneficial agreement, I move on. But most clients usually don’t care after I make that last point. Again, this will depend largely on the type of client you are dealing with (big bad corporations versus mom-and-pop-shops).
- Make sure you have a discussion with the client about open source software (OSS). Remember that you can’t promise that they can keep the application proprietary if you use certain OSS licenses. Make sure they understand the ramifications of you incorporating OSS into the code (i.e., they may have to distribute the source). If you are developing a web application, this will likely not be a concern. If they don’t plan on distributing the code you write, this won’t apply either. Remember that there are many open source licenses out there and that one may suit their needs (check the MIT license).
- Even if your client approves of using OSS, decide on your own if that is a good idea. Know the differences between the various licenses. Typically, I avoid licenses that “infect” my entire code base when I am only using a library. As such, I try to stick to licenses like LGPL when I’m using libraries. This is so that I can retain 100% ownership of the code. Please, respect license terms of code your borrow.
- Always remember to add your signature in the source code, especially in libraries. This is so that future maintainers can contact you and disputes about ownership can be proven. This would include:
- Your full name
- An email address
- Licensing or copyright terms, if any
- Make sure they own and register any domain names. You do not want to be bothered or responsible for owning their trademarks!
How to Build a Client Base – Web Developer Style
I had a fair amount of success when it came to getting clients long before I had my first programming job, and without any prior experience to show for it. This section is for aspiring developers hoping to gain experience and build a client base at the same time. Here’s how.
Disclaimer: Before I say anything, understand that contract work will not be a full time job, or even pay rent, for some significant amount of time until you build a client list and a decent portfolio. Many people keep contract work as a side income.
- Partner up with a designer. It’s best if you know this person in real life. Agree that you will split the pay 30/70 on sites with little or no coding, and 70/30 on database applications. The work won’t always be 50/50 or even 70/30, but it will help both of you build your portfolios, which is critical for mutual long term success. This is a fair deal for anybody starting out. Also, agree that you each own 100% of your parts of the project, but retain rights to claim the entire finished product as something you worked on. Picking a good designer is crucial.
- Now ask friends and family for anybody that needs a website, and do it for cheap. Here’s the catch that will help you get the ball rolling: if this is your first job, offer to do an entire site, with two design drafts, for only a couple hundred dollars (my first one was $250) with free support for a reasonable timeframe (a month). But the catch is that they must allow you as much time as you need. Almost anybody will take your offer. This is awesome for you because you are able to essentially learn and work on a hobby project at your leisure, but then get paid at the end! Make sure you do it in a timely manner (under 6 weeks).
- Choose your first project carefully. You will underestimate how difficult a project is. Do not, under any circumstance, agree to do a full content management system, forum, ticket system, or other heavy database application. You might finish it some day, but not without a ton of frustration and lowered expectations. It’s your first project: start small and grow organically. Try to do them a company or personal website that has a comment form, PayPal order system, or other relatively simple concepts. The moment you try to duplicate a major commercial product as your first project, you should realize you are probably shooting yourself in the foot.
- Each time you complete a project, up your rates by a hundred dollars. The beginning is slow, but if you are good at what you do, you will receive new business in no time. Eventually, you will start to see what your market hourly rate is.
- Part ways with the designer once you complete half a dozen projects, but stay in touch. Hate designing, but the job pays well? Sub-contract it out to your designer buddy! Is the job 90% design work? Just give it to the designer and take 10% of the pay for your part! The point is, you can each build up your own client lists while maintaining a mutually beneficial relationship with someone you have a proven work history with.
- On getting things in writing: all communication should be done over email. If something is said in person or over the phone, always follow up with an email confirming what was said. This goes back to the idea of having things in writing. Email records will act as evidence if you have a dispute. It’s a clever way of making sure everything is in writing without needing signatures and lawyers.
- On getting paid: host the code on your servers until full payment has been received. Don’t develop on their servers unless you really trust them or need the development environment. This is because underhanded clients may try to screw you. If you have all of the source on your servers, in a worst case scenario, you spent three weeks writing a cool application on your free time to add to your portfolio. If they screw you, keep the code and make sure to give back any money they fronted you.
- On getting feedback: when web-developing, always start with a mockup. Create some basic HTML pages to show the client. Keep it bare and ugly, but functional. Tell them to ignore the ugly look, but instead comment on how the page looks like it would work. Are there the correct input boxes? Are all the fields there? Are all the pages to be expected in place? You will use this mockup code later when you fill it in with real processing code. I can’t stress the importance of this development concept in terms of saving yourself time. Oh, and keeping it ugly will force them to pay attention to the stuff that matters: functionality.
- On aligning their expectations: after you pass the 85% completion mark, begin focusing your attention on how it works, not what it can do. Clients may initially judge your product by how it looks, but in the long term, they will judge it by how it works. This is different from what it can do. You might make the most advanced car ever made, but if the driving experience sucks, next year’s model will not sell. It’s the how, not the what. Non-programmers will always choose “easy” solutions over “difficult but more functional” ones. Just look at the iPod. When trying to figure out the user interface, always ask yourself, “Is there a better, more intuitive way to present this so even my mom could understand what this page does?”
As a side note, I am a developer today, thanks largely in part to my early contract work. It taught me a lot of important skills about managing deadlines, predicting development timelines, and interaction techniques with clients. Most of all, I graduated college with real stuff under my belt, unlike many of my peers who only had homework assignments to show for their experience.