Freelance Software Development Tips

Welcome back to our 3-part freelance software developer series!

In the first part of the series, we outlined some benefits and drawbacks of becoming a freelance software developer so you could decide if it was for you.

In this second part of the series, we explained how to become a freelance software developer.

In the this third and final part of the series, we’ll share some tips and tricks we’ve learned being successful freelance software developers over the years.

We have three sets of tips to share: communicating with your client, protecting your reputation, and solving common freelancing problems. Let’s get started!

Communicating With Your Clients

The first set of tips we’d like to share involves communicating with your client. As a freelancer, this is one of the most important things to get right! I find clients appreciate the following practices:

Be reliable: Be a reliable communicator, and answer emails and questions promptly. Also, avoid letting your clients wonder what you’ve been up to by sending regular status reports and/or letting them know when you achieve a goal.

Be polite: Be polite and professional, but just as importantly, be friendly. We are human, after all!

Be honest: Don’t lie, and always keep your word. Don’t make promises if you know you aren’t going to fulfil them. For example, don’t promise to implement a certain feature at the end of the project, if you already know that you will have troubles completing the project within the estimated deadlines, without that feature.

Don’t hide problems: Notify your clients of any problems as soon as possible, if the problem is serious and/or is going to emerge anyway, sooner or later.

Keep track of your time: Keep track of your time, and share it regularly with your clients, if you’re paid by the hour. If you work on a flat rate per project instead, it can help you figure out the difference between estimation and actual effort.

Offer technical advice: If you notice clients making a wrong technical decision, be sure to point that out to them rather than letting them flounder. Debate the decision, but remember that, in the end, the client always has the final word.

Ask questions: Don’t be afraid to ask questions; this can save you and your clients much headache down the road. In case of doubt, always ask, and avoid solving ambiguities based on what you think the client wants. When a requirement is not properly defined, or is missing important details, ask her to provide more details, or give her your version, so she can immediately spot any mistake.

Deliver what your clients expect, rather than what you think they expect: In software development, there’s often an expectation gap—the difference between what clients expect and what they really get. Eliminating ambiguities and avoiding assumptions when something has gone unspecified are good ways to minimize that gap.

For example, if a requirement states that a user shall be able to register by providing an email address and a password, and another instead says that a user shall be able to sign in by entering a username and password, you may notice that there’s an incongruence: registration requires an email (but not a username), whereas login expects a username. Should you use email during login, or should you also ask for a username during registration? Nobody but the client can answer that question.

Solve problems: When there’s a problem, focus on solving it rather than on complaining about it.

• Be reliable: Be a reliable communicator, and answer emails and questions promptly. Also, avoid letting your clients wonder what you’ve been up to by sending regular status reports and/or letting them know when you achieve a goal.

• Be polite: Be polite and professional, but just as importantly, be friendly. We are human, after all!

• Be honest: Don’t lie, and always keep your word. Don’t make promises if you know you aren’t going to fulfil them. For example, don’t promise to implement a certain feature at the end of the project, if you already know that you will have troubles completing the project within the estimated deadlines, without that feature.

• Don’t hide problems: Notify your clients of any problems as soon as possible, if the problem is serious and/or is going to emerge anyway, sooner or later.

• Keep track of your time: Keep track of your time, and share it regularly with your clients, if you’re paid by the hour. If you work on a flat rate per project instead, it can help you figure out the difference between estimation and actual effort.

• Offer technical advice: If you notice clients making a wrong technical decision, be sure to point that out to them rather than letting them flounder. Debate the decision, but remember that, in the end, the client always has the final word.

• Ask questions: Don’t be afraid to ask questions; this can save you and your clients much headache down the road. In case of doubt, always ask, and avoid solving ambiguities based on what you think the client wants. When a requirement is not properly defined, or is missing important details, ask her to provide more details, or give her your version, so she can immediately spot any mistake.

• Deliver what your clients expect, rather than what you think they expect: In software development, there’s often an expectation gap—the difference between what clients expect and what they really get. Eliminating ambiguities and avoiding assumptions when something has gone unspecified are good ways to minimize that gap.

  For example, if a requirement states that a user shall be able to register by providing an email address and a password, and another instead says that a user shall be able to sign in by entering a username and password, you may notice that there’s an incongruence: registration requires an email (but not a username), whereas login expects a username. Should you use email during login, or should you also ask for a username during registration? Nobody but the client can answer that question.

• Solve problems: When there’s a problem, focus on solving it rather than on complaining about it.