How to combine your main job and side projects

Many of us have plenty of free time left in the day. Why not monetize this time, the novice IT leftist thinks? If you work three hours a day on weekdays, take 2 thousand per hour, you will get 120 thousand additional income per month. Sounds great!

My name is Daniil, and through burnout, dismissal, disputes with customers and successful projects, I learned to combine a career in the company and running projects on the side.


Entry point

Together we will go through the path of the project, from approval to deleting the chat in the messenger, in order to trace the most difficult and dangerous places where the customer wants to leave you without your pants.

Project approval

The most important stage. This is where it is determined who will make money from whom.

The customer’s goal is to get results in a short time and less money. Of course, there are unicorns who are ready to pay you fabulous compensation, but this is rare. More often than not, the budget is tight and deadlines are tight.

Your task is to earn extra money without harming your main job. Re-read the previous sentence again. Primum non nocere.

Coordination is the search for a compromise between these goals. These are negotiations in which you have equal positions. The customer has a project and funds, you have the capabilities and knowledge. You have every right to offer conditions that are convenient for you and refuse those that are inconvenient. Most importantly, don't forget:

  1. You already have work, it takes time

  2. The client is more interested in getting results than you are

  3. You don’t hire a job, you don’t borrow money, you sell your services

My last project was completed under the following conditions:

  • I work and am available for discussion Mon-Fri from 16 Moscow time to 20 Moscow time

  • An hour of work at the set time costs 2500, outside the set time – 3000

  • Edits after delivery are paid separately

The timing of the project is a separate issue. If the customer has a deadline, for example, to make a website for the opening of a store, then there is no help. But often times are a negotiable subject, and here's how I count them (quite successfully lately):

  1. I break the project into modules (features)

  2. I evaluate each feature according to three parameters: understanding, importance, and basic deadline.

  3. I run all the features through the formula and add them up

ttot=(tbase*n*k)*1.7

n – understanding indicator: 1 – understandable, 1.5 – not entirely clear, 2 – not clear.

k – importance: 1 – important, 1.5 – not very important, 2 – not important.

70% on top for debugging (although I would add all 100).

It turns out that for a feature that I would rate as understandable, important and implementable in 1 hour, the total time would be 1 hour 42 minutes => 2 hours.

If the same feature were incomprehensible (required research) and unimportant (would be left for later), then the time would be 6 hours 48 minutes => 7 hours.

Yes, some will say that such a calculation inflates the project. But that’s the essence of trading – starting from the most advantageous point. It’s better to agree on an inflated deadline than to miss the deadline, because “Damn it turned out to be so difficult”.

Project work

Maintain the board even if the customer is not looking at it!

Ideally, you hand over part of the work and move on to the next one. In fact, home-grown Musk comes up with a seven-wheeled bicycle for pigeons every day. The project is overgrown with guesses, changes and jokes. And you should record each such trick on the board, so that in case of disputes you have the opportunity to demonstrate to the customer the entire chronology of the delay/error (if, of course, it was his stuffing that caused this situation). Moreover, it is difficult to keep the context in mind and not miss anything.

A solo project is always a temptation to add gags, to neglect the architecture, the purity of the code and all these paraphernalia imposed by companies. But this is a mistake. Your task is to find a balance between the quality of the code and the deadline for writing features. Inevitably, like morning after night, you will expand, rewrite, and add to existing functionality. So prepare the ground right away – write clearly, leave comments as if someone else will work with your code, and not you.

Manage the repository as if you were working on a team. Mark commits with prefixes, try to commit more often, divide branches into tasks. Always be prepared to make/roll back changes quickly. This will save you several dozen hours in the future.

Don't let the customer change conditions on the fly. Everything must be recorded, discussed, recalculated. Let me give you an example: I estimated my first project at 2 months and 250 thousand. compensation. After a month of work, the customer, on the advice of a friend, wanted to change the protocol (it was a VPN application). As a result, the project took six months. I'm literally stuck with it, and that's without renegotiating compensation. If you don’t want the same, fix the agreement.

The most important thing at last is to work forward. First, cover your tails at work. Avoid overtime, debt, and problems with managers. Close tasks on time so that after work you have a clear mind for projects.

Adopt work experience – for sure, the company you work for has considerable experience in organizing work. Study! Use your experience for good!

Project delivery

Passed? Goodbye.

It would be more correct to consider not the delivery of the project itself, but rather the delivery of some work on the project. Let's look at the situation:

You authorize via phone number. Having experience in this matter, you offer an authorization service through a call, where the user must enter 4 digits of the calling number. But the customer insists on a regular SMS. You fix the agreement, you submit authorization, the customer tests it and accepts the work.

A week later, the customer comes to you with the words “I spent 20 thousand on SMS, they are terribly expensive, change it to a call.”

What will you do in this situation?

What to do

Your moral superiority does not matter at all, so you can keep the phrase “I told you so” to yourself. But, absolutely, you must carry out this edit as a new job with a separate payment. After all, you have already submitted the task, the customer has accepted it, everyone is happy with everything. It’s like eating a salad in a restaurant, and then demanding money for it, allegedly there was hair in it (even though the plate is already empty).

By allowing the fixed agreements to be violated, you are simply driving down your own price. If you are ready to work two hours instead of an hour for the same money, then you will be ready to work three or four hours. So they get stuck in projects and endless edits.

Project support is a labor-intensive process that also needs to be discussed. It is very important to separate it from the main work so that the project has a clear finish. There is no such tablet where it is written that since you have done this project, then it’s up to you to continue working on it. The customer paid for the agreement, not for your soul. When all agreements are met, all functionality works as discussed – take the money and leave.

Of course, if the customer is willing to pay for support, and you have the resources, then this is to everyone’s benefit. But! Everything above remains relevant. Fixed agreements, clear tasks, no charity.

Accumulation of experience and portfolio

Each project will expand your competence. With each bump you will turn into an increasingly seasoned and seasoned developer, and after some time, you will be subject to an even more difficult task – managing another developer. Then your small one person company will turn into a small outsourcing studio.

Soft keys, friends.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *