Brennan Dunn

I've been consulting since 1995, and have been co-hosting the Freelancers Show podcast (https://devchat.tv/freelancers/) for about 5 years now. If I could distill all of the advice I've given (and received) over those years, it would come down to a few things:

(1) Consulting means running a business. This requires a different set of skills, and often different thinking, than you have as a developer. You'll have to learn budgeting and marketing, among other things. Learn these skills, and realize that for as long as you consult, you'll need to improve at them.

(2) There are many different types of consulting. I personally do Python training, and love it. But many consultants do what's sometimes called "staff augmentation," working as a contractor on gigs that can last one day to one year. Staff augmentation is the way that most people start off, and it's not inherently bad -- but you can make far more money, and have more influence and satisfaction, by providing insights and value from your experience and knowledge. And yes, this often means that you can make more money diagnosing problems and architecting solutions than actually developing the software that solves the problem. Also, the higher the level at which you're working at a company, the more you can make; helping a team leader is better than helping a programmer, but helping a VP is better than a team leader, and helping the CEO is better yet, still.

(3) Don't forget to budget, and to put money away for a rainy…

> Professional freelancers, that refuse to work for $5, seem to be losing the battle against an army of low-rate workers on sites like Elance, Odesk etc.

I disagree, but you made the statement. Can you back this up?

I don't think there is a problem with these "freelance markets." As with any market, it's a crazy, chaotic, noisy place with prices all over the board. The so called $5 workers occupy a niche just as their higher paid counterparts do.

Perhaps the missing ingredient is education for the customer. Again, each of these types of workers are potentially helpful for different cases. The difficulty for the customer is to figure out the landscape. I have heard many stories of people having a hard time doing this in the beginning but after blowing through X funds and trying out X developers they eventually figure it out. If money isn't an issue in this case, then the time may be an issue.

For the developer, the fix is to break out of these markets and attract potential clients with your own brand as opposed to piggy-backing off someone else's platform.

There are resources all over for finding out this info. Patio11 is quite active on HN and posts a lot of great info. Here is an example article from Brennan Dunn

http://doubleyourfreelancing.com/high-value-clients/

And a quote from that article.

> This is going to have you seek out clients who have problems to solve, rather than clients with projects to do.

As a consultant, you're end game is to become a partner to…

If you've been successfully freelancing for 7 years, then it's likely that you already know much of what I'm about to write. I'd say scrap partnerships and salespeople, and focus on what sales channels are best for you, online or local, whatever works. The two most important lessons I've learned in consulting so far are:

(1) It's really all about trust. The client wants someone who can reliably solve their problem, and tooting your own horn has a very limited effectiveness in building that credibility. Trust heavily impacts what projects people will give you, and how much you can charge. It's common that a company will somehow find 2-3x budget to hire a partner who they know will get the job done.

(2) Referrals and good deeds are the fastest way to build trust. When you come well-recommended by a prospect's trusted friend or partner, then a good amount of that trust gets instantly transferred to you. This transitivity of trust is key to building a good referral network that will consistently send work your way. If you don't have this, then you have somewhat of a cold start problem. In this case, providing value to people on a regular basis could really help with establishing your credibility. I don't mean doing projects for free, but more like offering people free 30-minute consultations about how to build their things, or sending them resources (articles or books) on a consistent basis that would really benefit them. This demonstrates that you can already deliver value,…

Productized consulting is where you take what your consulting does and turn it into a repeatable product. Some links:

https://doubleyourfreelancing.com/3-great-examples-of-productized-consulting-services/

https://www.karllhughes.com/posts/scaling-services (writing)

The goal would be to find something that you offer that you can make repeatable. You didn't talk much about the services you offer (other than the fact they are 'dev services'), but some examples for a dev shop might be:

* architecture review
* seo analysis (if you do webdev)
* accessibility survey (if you have the skills/desire)
* disaster recovery audit

All of these are tasks you can put a single price on, that you can turn into a process, and that have value to the customer disassociated from the hours used to deliver it. That means the first one might take longer, but you can start to optimize the process and therefore make more profit.

As far as hosting, if you build applications, you can offer hosting of those applications. Even if you are building on a cloud or PaaS (like firebase or heroku) you can still offer to manage applications over time. This would include doing things like setting up alerting, handling dependency upgrades, and managing the cloud or PaaS provider.

The value to clients when you do this is that they don't have to set up and manage their own hosting. Since you built the application, you probably know how to run it pretty well too. This can be recurring revenue that…

I did this around October of last year out of necessity and started doing it because I wanted to in January. So far it's going quite well. Here's roughly what I did:

First, read everything patio11 and Brennan Dunn have written on the subject.

Start here:

http://www.kalzumeus.com/greatest-hits/

and here:

http://doubleyourfreelancing.com/

Get yourself a website. Don't spend a lot of time building this, just on the content. It's stupid easy for developers to get sidetracked working on their own site and rebuilding it in Hot New Technology X every two weeks; don't bother. I recommend Squarespace as it makes it easy to setup & change content as well as track some basic metrics. Make sure it's very clear what you do. Separate it out into Articles for SEO, a Portfolio, and a page about working with you. Write articles about things you're very, very good at and at the end plug yourself.

For examples, I have:

http://<domain>/articles/

http://<domain>/portfolio/

http://<domain>/app-development/

Regarding a portfolio, there is no reason you cannot include the programming you did as part of a larger project. Just make sure that you accompany each entry in the portfolio with what your responsibilities were and how you contributed and why it was a success. Link back to other key members of the project, too; they'll appreciate it.

Next, I set up something to drive traffic to my website. Think of something interesting that would make a potential client say, "Oh, that's pretty…

I've been around for a couple of RFPs(1), and the company I work for had one for a CMS recently.

The way it works is:

1) Business has a crappy, very manual website/intranet/whatever.

2) Someone with the actual capability to do something (CIO, manager, whatever) decides this has to change.

3) Input is asked from people from the business and people that are nominally technical. Usually the people that actually know the requirements or are going to maintain the new system are not included.

4) Other people from security, audits, etc. chime in

5) Someone (business analyst or project manager) transforms the laundry list of requirements into an RFP.

6) Business approves the RFP. It is sent out.

There are companies out there that live on RFPs. If you're lucky, they'll use open source software, but they might re-package that into their own CMS.

Companies that have the CMS that ticks the most boxes in the laundry list have a leg up. It doesn't matter if it's shitty and buggy, it's VERY hard to write "non-buggy" in an RFP (if the company is wise, they'll have a trial period with competing products, but that costs $$$).

So, the company ends up with proposals in the hundreds of thousands of dollars for what could have been an in-house project (be warned, a mismanaged one can run in the hundreds of thousands too, even with open source CMSs).

A period of time later, company will select the CMS and will drop that info on the team that will actually implement and maintain the…