4 ms·

Glad it worked out for you. After reading this I’m motivated to start out as a freelance and can you talk to us more about how you turned this into a fulltime c

• gregjor 4y ago
  That's funny, all of the freelancers I know do it full-time. I started freelancing part-time when my full-time employer started losing money and laying people off. I had a friend who ran a web design company, he would hear from his customers how they needed web programming, so he sent that work to me. He introduced me to another design firm that had even more clients who needed help. From there it kind of snowballed. By the time I quit my f/t job I had replaced my income with freelance work. You don't have to freelance full-time, 40 hrs/week. You need to work enough at a good rate to get the income you want. If you were making $100k at a full-time job that's about $50/hr. If you can get $100/hr freelancing you can either work 40 hrs/week and make $200k, or work 20 hrs/week and make $100k. My advice: Get some customers first. Concentrate on establishing long-term relationships. That will mean doing some not-so-fun work and maybe expanding your range, learning the business domain, doing a little extra for the customer. Try to keep non-billable time to a minimum. Don't spend a lot of time/money on stuff like incorporating, fancy web site, business cards, complicated banking, accounting, lawyers. The biggest non-billable time suck for a lot of freelancers is finding and bidding on jobs. The less churn you have with your customers the less of that gig-hunting you have to do. You want to build a good base of steady customers who will refer you to other customers. Ideally you get your customers on monthly retainers, which turns you into a predictable fixed monthly cost instead of an unpredictable account payable. Remember that as a self-employed freelancer you have to pay all of your Social Security, Medicare, and health insurance, so factor that in when determining your rate. In the freelancing articles on my web site (typicalprogrammer.com) I suggest charging for specific tasks and deliverables, not big vague fixed-fee projects, not hourly. That doesn't always work, it depends on the customer and the task. You should have a target rate in mind, of course. If you want to make $100/hr and your customer needs a task done you estimate how long you think it will take and multiply by your rate to get a fixed fee for that deliverable. Then stick to that. Estimating large software projects challenges even the most experienced programmers and managers, but with some experience you should be able to estimate well-defined tasks that take less than around 40 hours. That also keeps you from getting in the position of your customer owing you a lot of money, or you owing them a lot (because you took a 50% deposit up front on a $20k project and you can't deliver, or you client refuses to pay the remainder). I vary my exposure based on my experience and trust with the customer, but for a new customer I would not want to get more than $2,000 to $4,000 in the hole, so I will break their tasks down into small measurable deliverables I can bill for.
  • cweagans 4y ago
    > You need to work enough at a good rate to get the income you want. If you were making $100k at a full-time job that's about $50/hr. This is further clarified in the rest of the comment, but I wanted to call attention to this. Be really careful with this line of thinking. It's not an apples-to-apples comparison, especially given higher costs and potential downtime between contracts. I recommend billing about 30% more than you'd expect out of a salaried position. > I suggest charging for specific tasks and deliverables, not big vague fixed-fee projects, not hourly. Why do you recommend this? For beginner freelancers, time and materials is an excellent way to go. For fixed bid (on any scale), if you overestimate something and get it done quicker, you get a nice bonus. However, if you underestimate something on a fixed bid, you're now eating the difference. In my experience, software projects tend to trend higher than estimated way more often than lower. This seems like a recipe for an unexperienced freelancer to get screwed by their first engagement.
    • gregjor 4y ago
      Hourly (time and materials) seems the most common, but customers will still ask you estimate for tasks. If the task gets big you will feel tempted to make up a number that feels right and multiply by the hourly rate. That turns it into a big fixed-fee project. Which leads me to... Big fixed-fee projects -- tens or hundreds of thousands of dollars and schedules that run for months -- open up too many opportunities for misunderstandings, and leave both parties exposed to owing or expecting amounts large enough to lead to lawsuits and arbitration. Instead I propose a more agile (in the original sense of the term) process, where the freelancer and the customer first break the project down into smaller pieces, in order, that have clear deliverables and price tags. That gives some advantages: - More frequent review and feedback from the customer, which keeps expectations aligned. - Less money at stake at any time for both sides. - Customer sees constant and measurable progress, which will either make them feel better about the schedule and budget, or support discussions about a possibly unrealistic schedule and budget. - Project has more velocity and more feedback loops. The customer develops trust in the developer for delivering, and the developer learns more about the business domain and the actual requirements. I have seen many freelancing projects written up as fixed-fee that then go sideways. A couple of years ago a customer came to me after losing $65,000 on a web site rewrite that dragged out for eight months, and at the end what they got was not usable. Not a huge amount of money but that represented the customer's entire budget for the project. So we reviewed how that happened. The contract was typical: $65,000 total, half up-front to start, with vague requirements (a single page) and a schedule that seemed realistic before any work started. The developers staged exactly one demo site in eight months for review, got some feedback, then started billing for "change orders" based on their opinion that the customer was changing the requirements mid-project. Once the entire budget got spent the developers stopped work, demanding more money. Lawyers got involved, arbitration scheduled (mandatory in their state), that's still dragging on. No web site to show for it. In hindsight it seems obvious the customer should have required the developers to maintain a staging site and push changes at least weekly, with a process for the customer to give feedback and change direction. If the project was broken out into iterations, with clear deliverables, the customer could have seen much sooner that the developer was off-track or not producing, and the developer would have known about requirements changes much earlier in the process. If they had decided to call it off at any time neither side would owe or expect tens of thousands of dollars. Writing complete and unambiguous requirements for non-trivial software projects remains a holy grail of programming. Almost no experienced developers can do it, and in my experience customers can't even start -- they think in terms of how their business works but may not even know how to describe that in sufficient detail. Knowing this well-documented fact of software development that every professional should understand (since we've known about it since at least the 1960s), agile as described in The Agile Manifesto outlines an alternative approach based on frequent small releases, review and feedback, iteration, measurement. I think that approach has a higher probability of success, or at least lower probability of massive and contentious failure, than the usual price tag with vague specs as a one or two page exhibit on a boilerplate contract. Focusing on deliverables forces both parties to define what they expect. Developers have a better chance of giving good binding estimates if they have clear specifications and bite-sized tasks with clearly-defined criteria for "done." The bigger and more vague the specs the more chance for misunderstanding, and those misunderstandings multiply and compound the longer the project goes on. Programmers should expect requirements to change and details to emerge during development -- that is the norm when writing software, not an exception you submit a "change order" for. We're not assembling Legos -- we're writing new code from scratch and refining it until the customer agrees it's done. "We need a new web site that lets our members list their talents in a directory. It should let new members join and pay online, choose their directory categories, upload photos and videos. We have several membership models and prices. We also want to show ads on the site." That was more or less the original spec in the contract for the project I described above. It had a little more detail but not much. The developers responded with mostly technical jargon: "AWS EC2 medium instance, Python/Django and Postgres back-end. Client will pay for all graphics, fonts, assets and provide full copy for web pages." I think it's obvious that combining the specs and the development plan, if you can even call it that, does not produce requirements anyone can estimate, schedule, or code from. It's just a recipe for conflict and disappointment.