A few days ago, I wrote a post about how freelancers and clients should manage their relationship and be realistic about expectations. Read it here. Today, I will talk about things freelancers can do to protect themselves.

It’s not unusual to have product features change during the development process. This is common especially when new ideas are uncovered based on user research or changing market requirements or even regulations. Nothing unusual here.

Now, this kind of request should be accommodated if within reason.

Let me explain, assuming you were building a simple calculator and a variable say interest rate was hardcoded and somewhere along the line, it became important to make this configurable, such that if the market rate changes, the interest can be adjusted on the fly. By all means, this is a reasonable request and one that both parties should sit down, talk about it and consider.

This is a market driver requirement and it isn’t unreasonable.

But the problem arises when an entirely new, not previously discussed, product requirements show up. Then this isn’t acceptable.

For instance, let’s say the application was supposed to sell cars, then mid-development, the client now wants to offer loans to users.

Here is why this isn’t acceptable. The feature set for a car sales website is different. A typical app for car sales will have car images(carousel), car name, model, year, colour, mileage, type, description, cost and possibly a button that you can make inspection request.

Loans, on the other hand, is a different beast. Feature include user verification(BVN), payment instrument for loan retrieval(card/account number), modelling for loan disbursements(how much money you can get based on some parameters).

Loan duration, loan default and penalties, arbitration, chargeback, retries for failed charges, payment reminders, etc.

Do you see how this is now getting complex? So as a client, you can’t just drop this on the thigh of the freelancer just because you can. Recipe for disaster.

So how can freelancers protect themselves from changing requirements?

First and foremost, resist the urge to take on a project just because the money is “good” and you don’t want to lose a client. Sit down and talk about the product requirements.

Document it, break it down into user stories if possible. Run this multiple times with your potential client and make sure both of you are on the same page.

If your client is technical, run them by possible technology choices. It doesn’t hurt.

It will be more frustrating if they come back a few months down the road and ask you to change tech choices because they will have issues with maintenance.

Ask for their brand colour and assets if they have one. This important, do this before you begin the product design phase.

Don’t begin development until you’re done with product design, carry the client along while the product design is in process. If you can, I think you should, prototype the product.

This will give the client a good idea of what the end product will look like.

It will save you a lot of stress in future like “make the design punchy.” “The button doesn’t pop.” “Let the design be glorious.” “Can the logo fly from the left and the text slide in from the right?”

Carry the client along and get a sign off for this phase.

Is it a slow process? Absolutely. But it will reduce frustration in future.

When the sign off is gotten, then you can begin writing code.

The above process is super useful if you’re using a flat fee billing method. But if you’re using an hourly rate, then things are diff.

If for any reason, there is a disagreement in future with regards to deliverables, then refer to the product requirements document(PRD). This is one easy way to keep your development process streamlined and manage expectations too.

For the client, in other not to get disappointed when talking to the freelancer, try and be articulate with your product needs, be verbose and don’t just say I want to build “Airbnb.” It’s okay to use another product as a reference, but be clear on your product features.

Spend time talking to other people, speak to someone technical, ask questions from your potential users. Ask features that will be important to them. Sketch out idle usage scenarios. Put in the work. The more work you put in, the less disappointed you will be.

Understand that the product you want to use as a reference took ages to build. So if you’re looking to build a super app, start with one feature, ship that and build iteratively.

These have a couple of benefits, you will learn from real users and understand pain points

Freelancers, be transparent about the cost too when putting together your initial doc. Most non-technical clients think the initial payment you both agreed on will cover the application hosting and maintenance in perpetuity. Not their fault, educate them.

Let them understand that some costs are elastic and charged monthly(cloud infra), while some are charge annually(domain).

Don’t ever top up any money for any external service. If you need 2 machines, get money for those two machines. Don’t lie, never LIE.

Avoid the “help us, we are family/friends” syndrome. It always ends in tears.

You’re better off charging more than trying to make a few bucks by topping up on fees from SaaS tools.

While estimating the product dev duration, make room for overflow. Don’t just settle for 3 months.

Ask for 4 months. This extra month will allow you to deal with unforeseen technical issues. Your client wouldn’t understand it, but you do and you need that time to deliver properly.

Resist the temptation to take on more projects than you can handle. Don’t do it.

Lastly, charge for that initial product requirements doc. It takes time to put a proper and comprehensive product requirements document.

Most clients will go quiet after getting that doc. You want to be compensated for your time and effort. You have earned it.

Oh, you’re better off doing a gig for free than undercharging.

Undercharging has the potential to breed resentment when you realize the workload is a lot harder than you had earlier anticipated.

Avoid the “help us, we are family/friends” syndrome.

I'll love to hear from you

Do you want to say hello? Email me - celestineomin@gmail.com

I tweet at @cyberomin