Top 3% Freelance Experts for Your Business

 It finally happened, you found a client and they want software from you! Congrats! Now we jump to the second part which is negotiating. This is a crucial skill for you to gain as a software engineer (if you’d like to learn more, you can find more content about communication here).

 Usually, when you talk to a client, they want a budget idea from you as quickly as possible — and here’s where things go bad, software time is HARD to estimate, so, if you rush things out here, there are only two possible outcomes: you overbudget it, and the client won’t like it or you underbudget it and you’re going to work for free.

 Besides budget, they also want to know dates and time ideas, because they don’t have a clue if their project is going to take a week or a year and the cycle repeats, only two possible outcomes, or you’re going to cut short, having to work way more than intended or you’re going to put too much time for the client to be comfortable with.

 Your job here is one: simply calm the heck out of this other anxious person you’re dealing with. They want to know things, and they want to know them fast, you just have to remind them that this is an engineering process and you’ll have to make some refinements before coming to the budgets and dates with precision.

 Sometimes, you’ll find some clients that are especially anxious about wanting to know things, here, if you have done some freelancing before, you can try to eyeball a range to make them more calm. If you’ve never made freelancing and you feel that this client is this edge case, ask someone with freelancing experience how much you should charge and they’ll help you out.

 Here’s a good thing if your customer is acquainted with you in some manner: you’re probably not going to go deep into the legal stuff! But, honestly, at least some contractual idea is generally necessary — everyone is great at demanding stuff, but not everyone is great at paying for the stuff they demand. Haven’t made a contract and your money didn’t arrive? Well, that’s bad — at least you learned something. The funniest implementation of a solution to this problem in my opinion is this one:

 It’s important for you to get some sense into your country's regulations for taxes and informal jobs like this too. You don’t have to dig deep initially, but just learn a little bit about how things work and which taxes if any you should pay for.

 Now that we've covered the basics of finding clients and handling the business side of freelancing, let's dive into the core of what makes a successful freelance software engineer: effective project management and engineering practices. As a freelancer, you're not just responsible for writing code; you're also in charge of managing the entire project lifecycle. This includes several key aspects:

 After estimating the features, add some extra time for the chaos of the world, bugs, or revisions. This practice helps manage client expectations and ensures you have room to deliver high-quality work — this is the goal since this is what is going to propel your organic reach.

 Throughout the years of freelancing, I tried a bunch of different tools to help me actually organize my process. It took a lot of trial and error only to realize that no tool perfectly fit my needs — in some cases, they were too complex, bringing tons of functionalities that I didn’t use, in others, they didn’t have some essential stuff.

 The great part of this is that I’m an engineer! So, throughout the past month, I worked hard to create a solution to help manage the business side of this. It’s called Founders Kit and I’d love it if you could help us on Product Hunt and check it out ;D

 Hey! You made it to the end. I hope that you have started to realize how freelancing in software engineering can be a rewarding and challenging career path, which can earn you some extra money and grant you some really cool experiences.

 Hello, In your opinion, what's the best way to deal with third party costs, for example the hosting costs or storage (S3) with clients, do you charge a monthly fee and take care of it, or do you ask them to create an account and ask for the tokens?

 Honestly, my take on this is that these will highly depend on the expected resource consumption of each project. If you receive a project that could take a lot of resources over the long run, I usually prefer to have them create the accounts, since that puts them in control of financial cases. That generally comes with the hassle of asking them for tokens, keys, and all the other things, so, I usually evaluate this really early in the planning stage.

 If you're doing a small website, with low resource consumption and/or think the client doesn't have a lot of technical ability, charging a monthly fee or a straight-up one-time payment to cover these costs can work, but make sure to clearly outline the terms in your contract (e.g., what happens if the costs exceed the estimate, when and how you’ll review fees, etc.) -- to be fair, most of the freelance jobs I did to this day never crossed the expected threshold, but, you never know.

 For cases A and B, I normally make sure that everything is in the client's name and control. This allows me to easily walk away when project is done and the client will not be in a position later on where they are held hostage to me and my availability regardless of the actual cost. That includes domain names, SSL certificates, copyright notices, cloud infrastructure, source control, etc. (Plus, domain names and SSL certificates not in your client's name may take away some of the site's credibility.)

 For scenario C, sometimes it helps to evaluate whether or not what you're building can turn into some Software-as-a-Service (Saas), fully managed and hosted by you (or your self-owned one man corporation). The infrastructure cost can be spread across multiple future clients and/or you can just convince yourself that your out-of-pocket costs will just be part of your future company's success story. Don't be afraid to dream big!

 Holy crap! to be honest I wasn't expecting such detailed and well structured response, it was perfectly written and clear. Thank you so much, I really appreciate the time you took to write it and the knowledge that you're sharing with us here. I send you a huge hug from México!

 While I agree that Fiverr and the like are probably cr*p, I think there's still potential in more "serious" platforms like Upwork or (a lesser known one which I've come across) Gun.io (don't let the funny name fool you, it has nothing to do with weapons).

Hire a Hacker

 As always "it depends", and while I agree that finding customers "all by yourself" (not via a platform) is generally the best and nicest way, it might not always be feasible, or it might just take too much time (been there, done that) - these platforms were built for a reason ...

 The only time i tried Upwork. I took some time to answer throughly to the potential client and in the end, a couple hours later there was between 20 and 50 other applications so it is really demotivating. I don't feel like giving the time people deserve for nothing in the end.

 Yeah the number of applications on a given job is generally insane, I agree that that's really demotivating - I think that's ALSO a problem for the people who are hiring - who wants to wade through 50-plus applications? I think that's a problem which Upwork should look at - maybe they should cap the number of applications at 20 or 30 or something, I mean, 50 doesn't make sense ...

 And those applications can't all be brilliant, on the contrary - I'm seeing a lot of run-of-the mill, low-quality, copy and paste stuff out there ... I think that's where you can make a difference when you're really good, or better than average - try to stand out from the crowd, by presenting yourself in a way that projects a bit more "quality" ... there are also tools which Upwork offers which you can use in order to make yourself "stand out".

 Thanks! Yes, copy/paste "heroes" and "cowboy coders" aplenty, but an area where I think you can really make a difference as a dev is communication - asking the right questions, getting to the bottom of the issues, solving the "right" problems ... that's always where I felt you can stand out from the crowd.

 Personally, I've never heard of those two you mentioned -- to be fair, I lost most of my interest in those platforms after my bad experience with Fiverr, but, I'll be sure to put that on the list to give a check!

 And totally agree, these platforms were built for a reason and you never know when you're going to need them hahah, so, I'll surely keep them on my radar! Thanks a lot for that resource 🚀

 Thanks! ... well, Gun.io is a platform which probably virtually nobody has ever heard of (I'm exaggerating a bit ... but only a little bit), but Upwork is, well, it's like the "500 pound gorilla" in the "freelancing platforms space" :)

 But ultimately they're just "tools", they're a means to an end - for me it worked, but that doesn't prove anything, I think there was also a huge amount of luck involved - "being in the right place at the right time" ;-)

 Hello, I actually wanted to ask like suppose once we have created and given the software (or any product that we were working on) to the client and also received money from them. So basically our work is done here but you know if we create any software then it also need maintainance and database management etc. and this will be forever till that software exists. Now our work was to just deliver the product or the software the client asked for but if the client asks how to manage it further or asks us only to also manage it for long then what should we do in these both cases? Even if we just explain the client everything needs to be done in order to manage that software, the client still does not have a proper knowledge of it and maybe he/she will not be able to manage it properly and if they'll not manage it, the software will automatically start to throw any bugs or errors and they'll blame us for that. Now if the other option occurs that the client wants us to take care of that software further also for the long run but obviously we can't do that. So how can we handle such situations? How will that software and its database will be managed throughout its lifecycle? And what exactly should we tell the client to do in such situations? (Considering that there's only one person and not a team of many people who owns that business for which they asked us to make the software.)

 In terms of maintenance per se, if we promised we were going to deliver something in the engineering planning phase, we have to do it. So, bugs and unexpected behaviors are on our end -- I fix and don't charge anything for it.

 Now, sometimes, our clients try to disguise small improvements as bugs -- and those are different things. I usually have a rule of thumb of not charging up to 3 small improvements -- just so we can have a great partnership and the client usually will remember that good faith. If the clients ask a BUNCH of improvements that adds up to some hours of work, than, I think you should charge additionally. After all, those things were not prototyped nor planned, so, adding them at a later stage will impact your costs.

 In terms of database usage and infrastructure, I usually try to eyeball the usage/consumption of services by talking to the client and seeing their expectations -- if they are searching for a freelance to create a platform that will have to deal with thousands of customers, you can't put infrastructure costs on your end, but, if you're dealing with a small project, that might be viable.

 And lastly, in terms of how to talk with your clients, it's important to remember that they are non-technical people usually, so, try to abstract most of the complexity when talking to them, showing only the high-level overview and the costs each part requires. Here's a quick example:

 Instead of saying "It's expected that your customers will use an average of 25 GBs of S3 Storage, and increase the overall CPU usage, so, we are going to need to scale your servers to other EC2 instance ..."

 A better way to approach that would be: "Hey, it seems users are sending a lot of big files on our end and it might increase our costs by 20%. Would you prefer that we limit the file size or include that monthly cost (about 50 USD) into your package?"

Post a Comment

0 Comments