I got an email from a freelance developer friend. I have a list of associates with whom I collaborate (I get their help) when I am overloaded. The email had two inevitable questions,
First let me write a short note on my testimonials page. You can easily identify that all the testimonials listed are true.
All the above are public information and can be verified within minutes. There are more that twenty five testimonials listed and cannot be faked.
Okay let us get back to the two questions. With a decade of freelancing experience, I have come up with twenty laws for freelance web developers. If you follow that, a project will be a success.
When I say “project success” it means, client is happy. Everything else is a derivative of that. You get full payment, a good testimonial, repeat order, possible new reference and all the good things will happen as a by product.
Do not accept everything that comes your way. Play to your strength. You may have to spend time without projects, even then you should be ready to say no.
There are various reasons to not accept a project.
Unless you are able to estimate the work and arrive at a detailed work break down structure, do not accept it.
Sometimes a long-term client may bring a project on an alien territory to you. He may try to persuade you, because he is comfortable working with you. If you accept and fail, you will loose. Better explain him why you do not want to take the project and it will add to your respect.
Every project is a new beginning. As you keep on delivering project, there is a possibility to become complacent. That will lead you to underestimate a project.
Start as if it is your first freelance web project. Learning is critical a freelance web developer. Most of the times, you will be sitting alone coding from your attic.
There is no team to discuss, share and learn. It is all dependent on your thought process. If you start fresh, you will be receptive (law no. 12).
Spend more time on requirements phase. As a freelance web developer you will not be billing the time spent on proposal process. Requirements analysis and elaboration is the most critical phase in a software development life cycle. Even critical than the design phase.
Unless you know what you are building where you will be headed. As a web developer, you will be dealing with intangible things. So it is important to get the detailed requirements upfront.
If you are working based on fixed rate, then waterfall method of development is best suited. You need to fix every inch of the requirement before start.
If you are working based on time and material (hour based billing), then agile iterative development methodology is fine. It is suitable for projects, where the requirement has to evolve over a period as you build.
In both the cases, write the requirements. Ask the client to write a document and email to you. You analyze and elaborate it. Write it as a document and circulate back for feedback. Iterate the process and arrive at a final document. have the conversation recorded via email as it will help you later to recollect.
Telephonic conversations has to be converted to a document. At the end of the phase, there should be a requirements document as detailed as possible.
Do not assume things. In particular when it comes to money, do not assume. There are numerous ways the freelance developer world works.
Explain the terms is detail and get the acknowledgement. Do not shy away from it. Discuss the percentage breakup, schedule, milestone, billing rate, fixed or hourly etc and the mode of payment.
Understand the emphasize is on money. It will also help to plan his budget allocation and be prepared for payment. Never ask for ad-hoc payments. Stick to the agreed schedule and payment mode.
Before the project is agreed, the plan should be in place. It should have detailed work break down structure with milestones. The plan should be approved.
You should initiate this process even if the client does not insists on a plan. You should voluntarily commit to it. If you do not do so, it will allow for micro management and ad-hoc reporting.
Client will be guessing the progress and will be on his toes. It will subject you to pressure. Working without a shared plan will never be an advantage for you.
This is not to be on the safer side. This is for a commitment. This is a business. The client has to get involved from day one. He needs to invest on it. You will be investing your time and building the product and for his part he needs to invest the money. It is mutual.
Beginner freelancers fear for everything. If I ask for advance and the client says no to the project, I will loose an opportunity. Working without a commitment is even worser.
Next, how much to ask is the question. In the freelance web developer world, it is customary to ask for 50% advance payment for smaller (less than 1000 USD) projects. For projects larger than that, the payment can be in three or four parts. Can be even tied to milestones (law no. 5). But whatsoever, there should be an advance to start the project.
A freelance web developer will always have an urge to commit a project, take advance and jump coding immediately. All these needs to happen immediately. There will be fear of losing the order. But you have to resist that urge.
The more the time you spend on requirements, it will save you later. Remember money is not the only objective. You should retain him for a repeat order, you need to get a testimonial from him, you need to get order references from him.
If all these have to happen, then do not rush into the project. The success is more essential than getting the final payment. Success encompasses more things than the final payment.
Client’s happiness directly relates to the success. A freelance web developer needs to step into his shoes. Should make all the effort to understand his objective.
A web developer’s key tool to obtain that objective is UI mockup. You need to invest on a fancy tool, monthly subscription etc. My go to tool is the good old pen and paper, sometimes color pencils will add jazz.
Just draw, write to create a rough sketch of how you envision the application. Take a snapshot and share with the client. Get his concurrence. Do not over work it. Remember you will be doing this in the proposal stage and the time spent is not billed. All you need to do is covey your idea of the understanding to the client.
A freelance web developer’s success depends on the strong grip on the project. The first step towards that is the UI mockups.
Establish a proper communication channel with the client. Along with the quote, share the ways using which the client can reach you. Give multiple possible channels,
A freelance web developer is like a juggler. If you loose balance at any point, the whole act will come down. For you to maintain the balance, the client should be comfortable.
Be easily reachable. Clearly convey the client that you prefer email as the communication mode. Attend to emails at least twice a day. Communication channel preference should be in the above order for comfortable execution.
IM and telephone should be the last choice in the list. It never helps. As a freelance web developer, I work with global clients. Imagine a client calling you at midnight and asking for a modification.
When the client writes, it will give clarity to his thoughts. So written communication should be encouraged. You should show that you are listening. In an email, never put any points under the carpet. Whether you agree or not, respond to everything.
If you are not able to reply immediately, just acknowledge and get back with details later. Your immediate response says that you are receptive.
Do not be casual and wait for client to talk to you. Every mail, ping, call should emanate from the freelance developer and not the client. This will give a comfort to the client. This will assure the client that you are taking care of the project and it is in trusted hands.
Initiating the conversation for a doubt from your side is usual. Every freelance developer does it. But the emphasise is on initiation to inform that the milestone is getting delayed, or you are not able to achieve a feature that you agreed. It might be a bad news, but have the courage to initiate communication.
As a freelance web developer you might follow multiple different models for development. In agile development methodology, it is imperative the way it works is by iteration and sprints. You show the progress, get feedback, iterate and keep developing.
A freelance developer has a mindset to get into a cocoon. Nature of the work style drives into it. You keep on developing yourself, there is no team, no one around you to ensure that you are on the right track. Here comes the client. Whatever model you choose, establish a schedule.
Do not be ad-hoc to show the progress. Before you write the first line of code, in fact at the proposal itself lay out a plan. What are all the dates you are going to show the progress should be transparently conveyed to the client. It will drive your progress. More than that, it will avoid rework.
Whenever you get feedback, give priority for the feedback. Not the regular planned tasks. Adjust the plan and covey the client. Always feedback goes first, it should not be accumulated.
A freelance web developer is an expert. The client does it for the first or second time. But you are doing it for the hundredth time. It should reflect in the work.
You are not a data entry operator, you are a developer. Lot more is expected from you. You should contribute in all aspects from design to implementation to training.
The client will have a narrowed down objective. He just focuses on only one thing, just the UI. You know the engine better. What component to use, how to modularize, how to make things interact, there are numerous aspects.
Sometimes enthusiastic clients take things outside the track and it might derail the stability of the software. That’s where you step-in. Say no, be steadfast and more important you have to explain and make the client understand. After all he is the one investing.
There might be some intricate things, as an experienced person only you will know. Explain it to the client, add value to his investment. Those will not go free and you will be rewarded.
As per law 10, you are supposed to get feedback in regular interval. This opens up other possibility, scope creep. Every feedback has to be organized into bullet points.
Feedbacks should be encouraged to be communicated in written form. If it comes in paragraphs break it down to points. That will reveal hidden gems. Client may not be doing it intentionally. He wants to get a product of his dream.
So he will be thinking about only what he wants. A freelance developer is doing business. Profitability is important. By informing the client that this is out of scope you are also helping him. Scope creep, will take you down. If you go down, the project goes down and so the client.
Explain it, give reference from the requirements document. Do not say no! A scope creep is an opportunity for a freelance web developer. Do not take it negatively and jump on the client. Explain him politely and increase the scope of the project and so the bill.
If an out of scope item is minor that can be informed to the client, reestimate the project, schedule and cost. Sometimes, the out scope item can be a module. If in proportion it is 50% of the current size or more than that, then it should be carved out as a separate phase.
Do not mix it with the current scope of work. Tell the client that you will definitely work on it. But will be taken as next phase. Let us document it and move forward with the current scope of items. Let us finish the planned work and then take this as a next project.
Re estimate and re scheduling can be done once or twice. If you keep on repeating it, then the client will get a feeling that things are dragged. It will feel like when this thing will end. So it is all in perception.
If you are billing by hourly (time and material), then this is not an issue. To be safe on this, people advice to always go for hourly billing and avoid fixed rate. Not necessarily.
If you are good in your territory, then fixed rate is fine. Client’s prefer that. If you are skilled enough to arrive at a good estimate, then why not? Go for fixed billing.
Freelance web development is a haunting story, most of the time. Despite you follow all these laws, expect unexpected turns. A freelance web developer has to swim in uncharted territories at times.
This may result in effort variation, remember plus or minus both. Sometimes you loose and sometimes you win. In any case, up to 20% variation is fine.
In situations beyond that, explain the client. Attribute proper reasons, give reference and evidences. It is your responsibility as a freelance developer to convince. Web development keeps on changing. A freelance developer needs to keep up the pace. Otherwise you will be in this situation quite often.
Developer’s responsibility is to ensure that the project is a success. In the success durability is also a critical element. A freelance developer is not expected to launch and run away (see law 19).
A web application should have a life of minimum five years. Without any maintenance project should run. But when there is a necessity, it should be doable easily. Either you or some other freelance developer might work on it in the future.
The comments you are going to add now will be of great help later. Freelance web development should not be seen as a one time job. If you do not add code comments, the same project may be freelanced to you later and the web application will come back and haunt you.
There are so many literature around the web explaining the goodness of source code comments.
As a freelance web developer, you need to draw your own rules. How do you arrive that? Is there any web developer template available? There is none. If you find something, do not follow it blindly.
Every freelance developer is a unique breed. Every web development project has unique challenges. You handle it in your own style. You have to arrive at your own rules.
But you cannot live without rules. For example, let us take non disclosure agreement (NDA). There are numerous template NDA littered all over the web. As a freelance developer you will come across many. Over a period build document for your own. Incorporate the best and keep updating it.
Hourly billing, fixed rate, what is your style. If fixed rate, do not keep it volatile. Which UI web component you will use? Which web responsive framework will you use? Right from money to tech stack, a freelance developer should have written everything. This is what you will follow, this what you will use.
What is your free support duration? These are all questions that are thrown at a freelance developer quite often. You should have readymade fixed answers for these. You should have freelance policy document.
The rope is holding you back. Did you see the movie “The Dark Knight Rises”? The scene where the batman tries to get out of the well (prison pit). It neatly sums up what fear does to you.
You are not exchanging illegal things. Holding a deliverable makes the client feel untrusted. Business requires trust from both the sides. If you have followed all the laws till now, the client will be more than happy to pay you.
You need not hold the deliverable and ask for money. It feels like threatening. You are a web developer. If you are confident that you have done a good job, do not tie the deliverable to the payment. They should be independent of each other.
No client will burn the bridge. If you do a good job and you make the client feel it, then he will pay you. Sometimes even more than what you agreed for. I have got paid extra many times.
The client will need you in the future in two cases. He may require you for maintenance or enhancement for the application you have built. He may also require you for new projects. So he will not attempt to run away.
To get the full payment, to get a testimonial, or for any similar objective, do not hold the deliverable. Your fear will make things worse. Be good and focus on client’s objective, then you will get everything.
You have delivered the project and the job is over. But, the client says it is not working. Never ever reply saying, “it is working for me!”. When he says, he means it.
If it is a web application, ask for access. First have intention to identify what is happening. Then think about how to help solve the issue.
How you respond to the call is important. Instead of saying working for me think about understanding the issue. Nobody cares about whether it works for you or in your environment. It needs to work in the production and work for the investor. Only then the developer job is complete.
Freelancer should always provide a support period. The terms may vary, but you should always provide support.
The terms of support should be discussed and conveyed at the proposal stage itself. For example, a freelancer can give six months of free support. Then what comes under free needs to be described.
Support is essential for the durability of the web application. For maintenance and enhancements will always be there. The client will bank on you as a first choice. You should be available for that.
Repeat work has higher priority than new job. Free support has higher priority than repeat work. That’s how it goes in the freelance world. That’s how you ensure project success.
“The crying baby gets the milk”, you should ask for it and there is nothing wrong in it. There are two main purposes to ask for a testimonial.
A freelancer’s worth is determined by the testimonials he has. It is your pride. It is far better and more important than a portfolio.
The words in the testimonial will teach you your strengths and weaknesses. Sometimes the client will not give you one. Don’t pester. Instead ask for what help should be done to make the project success.
Go the extra mile and make it a success. Then ensure that you get a testimonial.