Weekly discussion by freelancers and professionals about running a business, finding clients, marketing, and lifestyle related to being a freelancer.
Episode 273: FS 261: Q&A
FS 261: Q&A
This episode of The Freelancers’ Show features panelists Reuven Lerner and Jonathan Stark. They are answering questions from the audience. Tune in to hear their answers!
[00:01:15] When you sell someone an app or website, do you sell them a maintenance package with it?
Reuven does not. He charges by the hour. He would probably consider a monthly retainer. Jonathan thinks that for the typical freelancer, maintenance work is not highly profitable unless it is your main business. He calls it “janitorial work.” Developers do maintenance work because they think clients want them to. They think that because it only takes a couple hours a month it is something they can do.
What do you do when clients ask whom to call when something happens? Jonathan says he can’t help them but that he’ll put them in touch with someone who can. This may mean that he will put them in touch with a service provider or that he will train a junior developer internally who is capable of doing the work. If you are aware enough to recognize that when you sell someone a website build that they are probably going to need maintenance later, it can be an upfront guarantee or an option that you build into your proposal. Then you can give them a quote that includes bug free, guaranteed maintenance for a specific amount of time.
The ideal option for Reuven is to use a bug free guarantee as a differentiator between you and anyone else bidding on the job. This gives you a strong incentive to do a great job the first time around. An ideal for Jonathan would be to give the client a fixed price that’s high compared to hourly estimates. Give a guarantee that indicates quality, whether that’s a bug free guarantee or satisfaction guarantee.
[00:17:42] “Four Phases of Client Engagement”
Jonathan is not a fan of long-term developer employer relationships because he feels that they start to treat developers as employees. He references a blog post, the “Four Phases of Client Engagement,” which points out the four phases of engagement.
During the four phases, profitability is highest at the beginning phases and lowest at the end phases. It is easiest when doing a diagnostic because it is easy work for the developer and they earn a big profit while delivering value to the client. The four phases are:
- Diagnosis – This is where the problems or root causes are identified as XY and Z.
- Prescription – The stage where developers tell clients what to do about their problems.
- Application – Go and implement the plan. Most operate in this phase.
- Reapplication – The maintenance phase.
[00:22:10] What about businesses that offer specialized upgrades?
This is where the client finds himself or herself in a jam and needs help fixing a high-risk problem quick. There is a potential for a high profit to be made. If you have high risk combined with high urgency and your expertise overlaps with the problems that are there, this type of company can exist and make a high profit. In this situation, maintenance is not a goal.
[00:25:15] If I go to make a list of clients I enjoy working with and the list is empty, what do I do?
Reuven’s suggestion is that this person needs to find a different focus as well as different clients. Jonathan suggests picking a vertical. While this is easy conceptually, it can be hard to convince yourself that what feels like a risky decision is not. Jonathan suggests to look for where he has expertise. Find the common thread between his clients. Whether that is a vertical focus – a type of company - or a horizontal focus – a specific technology. He also suggests to look for a story to tell that could point them in a direction of expertise. There has to be a theme to his work. Find that and frame it to show value to potential clients.
[00:33:30] If a client asks me to do something that’s out of the scope of the project I’m working on for them, how do I politely say, I’d love to do that for you, but you’re going to have to pay for it?”
Software developers usually code. Extra work – such as sitting in on a meeting – that they may be asked to do is headwork, not handwork. This shows that the client trusts them, either through a relationship developed or through a conversation that was had about a particular expertise. If they are invited to a meeting, they should try to secure that opportunity. The wrong thing to do would be to ask for payment. At this point in the relationship, they still see you as a coder but are giving you an opportunity to affirm your value to their company. This is an opportunity to be promoted. Don’t act like a mercenary in this situation. Just go do it - even refuse if they offer to pay for your time. Act like it is a sales meeting. Deliver as much value as you can without doing homework. If it goes well, finish the meeting by saying that you have time to take this on and can write up a proposal. This shows them that you were happy to do them a professional courtesy but afterwards won’t take it further unless you get paid.
If you are an expert in the field you won’t be able to give away all of your knowledge on the subject in an hour. Taking the meeting gives them a taste of how it will be to work with you and why they should hire you. Getting leads is the toughest thing so you probably will not have more than one or two of these types of meetings a year. If you begin to have more meetings than that, consider road mapping. This is an opportunity to charge clients for something that they will appreciate and that is easy to do on your end. But it is changing your business.
[00:49:15] If I specialize on a vertical, how do I reuse code from client to client?
The general rule if you are writing code for someone is that your client owns the code. If you reuse the code, it could get you into legal trouble. There are ways that you can get around it. One way is to put in the contract with the client that you still own the code. This actually happens a lot. It can be structured in different ways. If you are modifying a library then that retains an Open Source license, so you still own the code. If you come into a project with your own libraries then those also still belong to you. Just make sure to always put it in your contract.
Picks
Jonathan:
Reuven: