1. Sales time is free. Even with established clients they are likely to work project by project and expect detailed quotes/estimates and initial discussions that take a lot of time, then there's billing and general business handling..

2. There is a forever war between large generalist consultants and niche consultants. Working ~alone you will probably have to be an expert in a niche and there is always business pressure to use a large consultant for everything even if their work is sub-par. (Accounts payable, etc, don't care about quality of consultants but about number of tasks.)

Planning for these factors is important, and combined with having no one to bill for more general maintenance hours and attempts of various orgs to get their "standard discount" for volume, being a startup, or being an NGO it is important to make sure you ask for a high enough rate. With contracting, seeking 1.5-2x is a minimum in most tax systems, with consulting at least 3x your intended income from an equivalent full time job.

It's all about your personal brand, to a large extent. If maintaining such a beast (with the help of requisite doses of self-promotion now and then) appeals to you, then consulting may be your thing. If it makes you go "ick" or "meh" on a certain level (and your aren't already saddled with acclaim / visibility based on your storied accomplishments thus far) -- or you'd really rather just code -- it may not be.

And also: as an employee or freelancer, your "client" (really your employer) tells you what to do. As a consultant, you are valued primarily for your ability to tell them what to do. Actually it's always a mix in every tech job above entry-level, between advising and just doing. But consulting definitely involves a much heavier tilt to the advisory side.

A small change in mindset that can have a huge impact in the kind of work you can get, and the image that people have of you.

You can also bring that mindset into regular jobs too, of course. You just have to be kind of oblique about it.

Contracting is when you undertake to perform a certain unit of work for either a fixed price or at an hourly/daily rate. Your deliverables are completed tasks - on budget and schedule.

Consulting is when you are a recognised expert in some field, analyze the client's situation/problem, design and document a solution and/or make recommendations. Your deliverables are reports and presentations.

You need to plan for spending 20% to 50% of your time and energy, networking, prospecting, preparing proposals, negotiating and chasing payments. Due to that overhead, you need to charge at least 2x-3x your salary rate. It is prudent to retain an accountant for the financial issues, a lawyer for contractual issues and take out insurances as required in your specific jurisdiction.

If you don't mind all the non-paying activities and the fluctuations in revenue, then consulting can be a lucrative means to a comfortable lifestyle.

As I work at a "real" consulting company maybe my experience isn't what you want, but I'd just suggest always focusing on networking and remember you are separate from the company you are consulting for. You can and should say no to things you don't want to do; setting boundaries makes it easier for yourself and the client. Pay attention to what the client complains about, and try to think of how they're trying to do their job(or whoever is to use what you're working on.) Never annoy your main point of contact at a client beyond reasonable amounts. Try to focus on clients in your timezone first. It is fake and a lie until it is written down in a SoW with a corresponding budget. Have confidence in the product you give but make sure your first few deliverables are 'perfect' as it will make the client much more amiable to working with you again. No client will admit what they want unless they just got done having to deal with it.

If you can find good ways to charge for your time in a sustainable way and get some support around you it’s amazing. However the paperwork and admin can be a bit challenging to someone used to a simpler and set up environment.

Reach out and let’s talk. I’ve been doing it for a few years now and love it.

I run PMHero.co, and did my best to simplify the whole process for clients. It's one monthly fixed price, so no contracts, sales meetings or hour management. It's self serve, so quite easy to create an account and get started (we use Trello to manage all the requests). It has helped set me apart from competitors.

Marketing your business and finding your first few clients is always difficult, but once you get rolling, it usually runs smooth. I also tend to be a generalist, and quite curious, so I can cover a lot of territory, which makes me a one-stop shop for the most part.

Hit me up if you have any Qs I can help with.

I'll reproduce it here:

0. Form:

0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.

1. Contracts:

1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.

1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.

1.2. Retain intellectual property to amortize engineering and sell what you make to others.

1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.

1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.

2. Presentation:

2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.

2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.

2.1. General presentation with broad strokes of your capabilities, including previous work with other clients

2.2. Conversation with the prospect on their worries in a given space

2.3. Conversation with the prospect on their worries in a given space

2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.

2.5. The client finds one problem urgent/highest priority/highest value

2.6. You get together and talk about "desirability, fasiblity, viability".

2.7. Once you agree on what to do, prove the concept.

2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.

3. Execution:

3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.

3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're in, you're in.

3.2. Listening and assuming the client is smart goes a long, long, long way.

3.3. Send meeting notes to the client. It clears ambiguities during/after the project.

3.4. Press to get the client's domain experts' collaboration. They will actually use what you're building. Get them at the table.

3.5. Some of the most valuable insights are gleaned after a meeting and not necessarily with your "counterpart".

Don't build the wrong thing.

4. Abstract:

4.0. When you solve many problems, some patterns emerge. You built custom products for your clients, but you can abstract functionality and build tooling to scale your services, and enable others to do the same.

4.0.0. e.g: we we built machine learning products for enterprise clients. After many projects, we built iko.ai, our own machine learning platform to "Get Data Products Released".

4.1. One advantage of this approach is to explore the space while being profitable. Some problems exist not for lack of a nice front-end or lack of knowledge of the target audience. Coming at them from a purely "webdev"/"devops" mindset can bring bad surprises.

All the best,

BTW. is there a separate 2.3 point or is it just a duplication error?