Hacker News new | ask | show | jobs
by mgkimsal 5525 days ago
I've got 'real' email addresses, but still use my gmail address with some clients, partially because it's one of the few things that I can be guaranteed to use at a client's office - I'm often blocked from anything except port 80 when I'm onsite. Yes yes, I can set up my own webmail, but I don't. And I'm not comfortable using google domains stuff, so I split. Probably 50% of my mail with some clients is over gmail, but I have multiple real domains, and much correspondance happens from there as well. I find some clients bounce around - they've got their 'work' email, but they exchange emails from 'home' accounts sometimes too. I don't consider them 'unprofessional' for doing so.

As someone else mentioned too, the 'have your own agreement' thing - well, I've got one, but have only used it a handful of times. More than half my projects have been with mid to larger orgs that already have their standard procedures in place. To use my own contracts either means I don't get the gig, or things will take a few extra weeks while "their people" review things, and they'll inevitably find something to complain about. They are not going to agree to resolve legal issues in my state if they're out of state, so, do I bend, or hold firm? There's no right or wrong answer - each person has different tolerance for this, and it'll probably change over time.

I understand the frustration with people just using the term 'freelancer' without really being a fulltimer - I started indieconf.com last year to address some of these issues that we all deal with, and avoided the term 'freelance' because I think it has a bad connotation. It conjures up images of the unemployed designer between fulltime jobs. Undeservedly so, perhaps, but that's what I was finding. "Independent web professional" is a bit of a mouthful, but conveys a stronger image (and encompasses more than just designers or developers).

The big danger anyone faces in hiring a 'freelancer' is that they won't necessarily stick around for the whole project, or may not be available later to provide followup support. Yes, you face the same with employees, but it's somewhat less of a threat in most cases. That was something I was surprised that the blog post didn't address (or did I miss it?).