Completely agree with the premise of this article. I'd even put communication slightly ahead of technical aptitude in the skills required to freelance.
I've just seen so many freelancers fall on their face because they built out what they envisioned as "done" rather than what the client actually wanted.
It's actually how I lost my first client. It was a two week Rails/Angular contract and I was focused on things such as clean code, contributing to OSS, and putting in tests. At the end of the contract the CEO said it wasn't going to work out.
I asked for a quick call before we parted and he revealed to me that he went with a consultant because he wanted to someone to know exactly what he wanted done and for them to just finish it independently.
It sucked failing like that for my first client after full time work but I'd rank it as my number one lesson in independent work.
Lean how to sell. When I was in college I got frustrated at not having software dev opportunities and only opportunities working at the mall (I went to college right after the dot com bubble). This curse ended up becoming a blessing because I learned how to empathize with what people wanted and what they were trying to accomplish.
A lot of freelancing is just being able to sell yourself. When you find a lead you have to convince them (aka sell to them) that you won't run away with their money and are trustworthy enough to finish what they asked. Each week/day/month you have to do a smaller version of this sale to convince them to continue to stick with you and pay you. Even at the end of the project you have to convince them (aka sell to them) that they should provide positive reviews for you.
Aside from selling you've got to be sure you deliver on time and perform the work asked. You'd be surprised how much of freelancing is more about soft skills (listening, empathy, communicating, saying no, etc) than technical skills.
If have any more questions don't hesitate to reach out to me at ryan at challengeacceptedhq.com
I write a newsletter on freelancing but have taken a couple months break to wrap up my book: The 7 Recurring Revenue Recipes for Freelancers.
A lot of salary negotiation and asking comes down to preparation.
It's terrifying to ask for one the first time but it's a natural part of employment. The basic principal behind hiring an employee is that they will become a financial net positive for the business eventually.
As an employee you can figure out how you affect the bottom line. It may take some imagination but you can come up with a ball park figure. In a larger corporation this may be a little tougher but with some digging you can come up with an idea whether you've become a net positive.
At the point you've become a net positive everything you make the company beyond your salary goes to profit or your bonus. If you're really good at your job then a lot of it is going to be going to profit. This is the point where you should ask for a raise.
Again it will be nerve racking but if you go in knowing how you affect the business's bottom line your raise will be justified.
I'd also suggest walking in with knowledge regarding how much people with similar job responsibilities make. This can be found on salary look up sites. A quick google search pointed me out to payscale.com and indeed.com
Great copy! My only issue is with the "How I Can Fix Your SQL Server Woes". Everything prior is the right level on the ladder of abstraction. This section needs to be more specific though since it is the last area besides the testimonials to handle potential client objections.
It needs to have actual use cases where your Dad's expertise helped these businesses. You can think of it as the bullet points in a resume. It may also help to include some kind of case study that formalizes your Dad's offering.
First I just have to say this was titled "How I launched a productized consulting service in 2 days that brought $15,450 worth of work in the first month" but that was a little long for HN :)
There are just a ton of things to learn from this article. I'm not sure if I can cover them all but I'll try
> freelancing service with a fixed length, scope, and price
This negates a ton of the pains of freelancing. You wouldn't have to go through a ton of contract negotiating on price and work delivered because everything is fixed a clearly define. You shouldn't have to worry about going past the end date of the engagement since you're offering a productized consulting engagement which you're an expert at.
What if anything falls out beyond what's defined in the scope and end date? Just define a traditional MSA and SOW. The process should be a lot easier since you've already established trust with the client which is usually what 99% of contract agreements are all about (not a real statistic).
> Announce LPIAD like a product
This is what I found particularly fascinating. This service can be launched. And by launching you outreach to thousands of potential customers you couldn't reach before. That's the ultimate cold call!
I'm glad that you've gotten so many takeaways but be very mindful of this. As you've said you didn't see a lot of these things when you just started out. It's through experience that things became obvious.
It'll take time but if you focus on teaching and improving your team you will get there.
It's never too late to switch or alter the direction of your profession. Plus you're asking for help which means you're moving in the right direction.
It sounds like you're at a bit of a crossroads. The first thing I'd suggest is to pick one thing and stick with it. Stop the learning.
If you want to get into programming and develop your portfolio the following is what I'd suggest
1. Create a github account.
2. Find a project that interests you. I'd look at this thread from the other day on what OSS projects need the most help with documentation for projects https://news.ycombinator.com/item?id=8551624
2a. As you're looking through projects, look for ones that have maintainers who show they welcome contributions and are willing to go the extra mile with communication. The way to figure this out is to look at past pull requests and closed issues.
5. Every time you learn something write about it and PUBLISH it
All this advice is applicable to working on two main things 1) Figuring out if you really want a career in programming 2) working on your weakness, which is communication in English. If you have any questions or want to talk about better next steps feel free to contact me. My twitter handle is in my profile.
This all depends on the environment you're working in. When we used to do lunch and learns they were on Fridays which were blocked off for side projects.
Plus half the time we did lunches it was as a team and we always ended up talking shop.
We also welcomed free food and had other people in the community come and speak. Now if you're in a culture where it's 100% coding 9 to 5 then I'd completely agree with you.
You need to stop thinking of them as 'coders'. When you think of them that way, you're putting them in a box and limiting them.
Instead consider them to be a team of people. As you said, each of them are at different stages in their career in programming. You need to understand this and sympathize with them and their code. This takes time and effort on your part to help lead the way.
You say that you review the commits now and then and find some of these issues, but do you bring them up? Do you show them how the code can look and read better?
If you do, make this a process and act as the person approving pull requests for the first several weeks. Then formalize this process and delegate this job to the next person who you feel writes high quality code.
Again a SHORT guide or book will not turn around the quality of your codebase and the team working on it. If you're interested in better code, invest in your team. Send them to conferences, give them a budget to spend on books, have book clubs and lunch and learns. Invest in the process of improving the skills of your team.
> what would you do when your gf/bf/wife/husband complains about it?
When my wife complains about it, I just listen. She's also a working professional who works a ton more than I do so it's usually a red flag if she brings it up. A lot of times it's not about coming up with a resolution but just trying to understand what she is frustrated with.
> So how do you handle this balance?
When I first started working remote about 10 years ago I didn't think it was an issue. It was supposed to be the dream setup.
But then I eventually had kids and started my own company and saw the lines between work/life blur. At first I told myself this was natural since it was one of the side affects of being remote but I quickly became dissatisfied with that answer. This was especially the case when I felt like I had to start choosing between time with my family and time for work.
I eventually came to realize that life stuff (i.e. family, relationships, etc.) aren't a time suck from work but a healthy constraint.
For me, success does not come from pouring every ounce of energy I have into work but from embracing the constraints of my life. I use these constraints to focus on the most important things I have to do for work so that I can get back to my family as soon as possible.
For more of a practical standpoint the following are the things I do to manage the balance (especially since my home is where I work).
Exactly. In one case I was associated with the work was done with a collaborative research grant. A laboratory had the need for a custom Laboratory Information Management System (LIMS). We built the software as they specified but retained ownership of the source. I know it sounds crazy because it's a win, win situation. Then we were able to market/sell that software to labs that had the exact same need (a niche market). Then years later I was able to secure a support contract for the original lab because I was the only one willing to support it. Which has in turn, turned it very specialized freelance work. All of which can be considered recurring revenue.
As pistoriusp alluded to I'm just trying to gauge interest. But to give you more details these are the things I'm focusing on with the book:
1. Word of mouth referrals. This is the old school way to get recurring revenue. But I've seen a lot of freelancers fail at this. Specifically, delivering the client exactly what they envision AND positioning the client to be successful. If they aren't successful, then they're going to be out of business soon, and that means you're going to have one less word of mouth referral out there.
2. Support contracts. If you've done a good job at 1, then there's a good chance that you're the client's only line of support for their project. Just because you've delivered all the code and launched the app doesn't mean the work is done. What happens if their users have questions or feature requests? What happens if their site goes down? By offering support contracts you can continue to invest in a client's long term success, keep that referral hot, and start building recurring revenue for your business by having a support contract that renews annually or quarterly.
3. Productized consulting. As a freelancer you learn a ton of skills on the job. Sometimes these skills are applicable to other clients. If so, you should package this offering. 37signals did this a long time ago by offering to redesign a single page on a site for a flat fee. I have interviews with people who are doing this kind of thing with Stripe integrations. The other side of this coin is that you have to position yourself as an authority on the package you are offering. By doing so you further diversify your recurring revenue by having leads generated based on your expertise.
4. Product sales. This is kind of the 'unicorn' of the bunch. If you are building an application for a client that has no interest in selling or owning it (i.e. research departments, internal tools for large organizations, etc) you can take ownership of the product and sell it to yourself. I've seen this happen a handful of times and it essentially multiplies your revenue because it produces work in 1, 2, and 3.
Author here. You're exactly correct. I have a ton of drafts on the book so far. But nothing I'm ready to release yet. I've actually been sitting on this landing page for months and was convinced to push it out.
Another way to approach this is to ask what they consider a day to be? Is it sitting in the chair from 9 to 5? Is it just doing a certain number of features in a day? Does it involve doing support after hours? Considering that they are asking for a 'day' rate I'm assuming this is their way of asking if they can retain you for full time work the extent of the contract.
In these situations I make it clear that while I'm willing to make them my primary client my business does require me to attend to other matters such as administration, taxes, billing, lead generation, etc.
I never say they can expect X hours out of me a week because quite frankly I've never been good at maintaining a consistent hourly pace per week. When I was doing hourly I averaged about 20 hours a week of programming (I was pretty fanatical about starting/stopping the clock). When I would get closer to 30 that was when I would be pushing a deadline or getting close to burnout.
What I do now is get a sense of what they expect out of me in terms of reliability and production. This tends to be a lot of work up front because I'm building trust with the client. Such as meeting with them more frequently to get on the same page as them. But that up front work pays off dividends later on when I have to bail to attend to family or business matters. Eventually this settles down to weekly communication to see if you're actually meeting/exceeding the client's expectations.
Again I'd emphasize asking more questions about what they consider a day to be? Who knows it might just mean you working on their stuff for 5 hours a day :)
I got a MS degree in Bioinformatics and for the past three years the only role it has served is collecting dust in my closet upstairs :)
I was the young bioinformatician in 2006 and when working in a lab it felt very isolating. The PI and Postdocs just had me solve simple computational problems (or even IT problems). It felt very much like I was a cog in their grant writing machine rather than a collaborator that deserved any kind of authorship in a publication.
And looking back there was no one to teach me about good practices of writing software like source control, SOLID, testing, etc. Or even storage of our microarrays.
I eventually went to work for a biotech consultancy but I discovered that biotech software was a gimmick used to hike up the prices on software. Sure it was a niche field but we would charge clients hundreds of thousands of dollars for software that was barely functional.
I think a lot of Research groups were badly burned by this and eventually started trying to do everything in house. I eventually became disillusioned/burned out and left the field entirely.
I've been out of the field for four years now but still feel badly as I felt I've wasted my training. I still have a retainer client as a way back 'in' back into bioinformatics.
It would be nice to find these 'bioinformatics groups' and see how they're successfully collaborating with other labs/research groups.
This is the exact same thing I do. In fact I wrote a little shell script (https://github.com/rmcastil/dotfiles/blob/master/bin/gtd) that I use once a day to get everything organized. It opens up all the files in vim so that I can quickly organize what I'll handle for the given day. When I'm in my shell and think of another task I run another script (https://github.com/rmcastil/dotfiles/blob/master/bin/inbox) that quickly appends it to my todo list. I try to loosely follow the GTD methodology.