10 Things I Wish I Knew When I Started Charging Money for Programming

Published in

Techspiration + Ideas + Making It Happen

5 min readJul 24, 2015

Learn from my mistakes, rather than yours…

I’m Reuven Karasik, 15-year-old web developer. I’ve been programming since I was 7, but I only started charging money for programming in the spring of 2013.

So I started “having clients” (charging money for programming) around 2 years ago. Today, after many clients, many mistakes, and many wrong decisions made over those couple of years, I just wish I could go back in time and tell myself a few things that could’ve made my life easier. Since I can’t do that, the best I can do is share it with you, in hopes that you will do better than me with your first clients.

Clients

These rules, of course, do not apply to all clients. But consider them when dealing with an average client.

1. The client doesn’t know what‘s good for him.

Clients often have no idea what is recommended and what they should avoid. It applies to design, to user experience, and simply to decisions that should be made. If a client asks you to put red text with a yellow background on top of a 50px * 50px picture stretched to be full-width, it’s best not to listen to them. Stand up for what would make a good product and for what would look good in your portfolio.

2. The client can’t evaluate work properly.

Clients can say sentences like, “Yes, look, if you don’t mind, and if it’s not too much trouble, and of course only if it doesn’t take more than a few hours, would you please increase the font size by 1px?” on one hand, but, “Oh– and it’s probably going to take a few minutes– but I need you to redesign the entire website and add a comment system to the app. Shouldn’t be too hard, right?” on the other. Clients don’t know what’s easy for us and what’s hard.

3. The client sometimes needs to know how much things cost.

Some people think a complicated social network should cost $100, and some think a 3-paged website should cost $3,000. Our job is to be fair with them, but to make sure we get paid what we deserve for the work we’ve done. Be careful when you give a price tag to a potential client, they might hang on to it later. (More on payments later.)

Getting (to) work!

4. Choose your projects carefully.

One really important thing to know when you get offered a project is when to accept it and when not to. If you don’t have time for that project, or you feel like you wouldn’t want to work with the person, or even if the project just doesn’t seem like something you’d like to do, say no. I can’t stress this enough.

5. Say no.

Learn how to say no. Not “yeah, maybe, but...” — just no. Whether it’s a project you don’t want, a deadline you don’t think you’ll reach, or anything that isn’t going to happen, the client should know about it as soon as possible. Countless times, I’ve told clients I’ll do something even though I realized there’s probably no way I can make it within the timeframe, and each time, I regretted it.

A great way to say no because of time limits is, “I wish I could.” It compliments them.

6. Payment & work evaluation.

Some people may disagree with me, but I believe — from my experience — that the best way to get paid for a project is per hour (unless there’s a very specific specification). Clients always add things to the list after the work begins, and if you set up a fixed price, you might have to “work for free” eventually. Set up a price per hour and keep a record of your time. I think the client would also feel that this way is fairer.

Learning

7. Don’t let your clients hold you back.

Two years ago, I wanted to learn so many things. I was a 13-year-old guy with great plans for the future and a clear vision of where he wanted to be in two years. Today, I’m 15, and although I’m very happy with all the things I do and I’m satisfied with where I am right now, I have to say that I didn’t learn even half of the things I wanted to learn. My projects held me back and didn’t let me learn new technologies (unlike when I was programming for myself). Keep time for learning.

When you stop learning, you start dying.

8. Use cool technologies.

I was once offered a project, and I had to choose between using jQuery (which I know well) and Angular.js (which I was only a bit familiar with). I didn’t want to waste my client’s time, so I chose jQuery. Very good, huh? A month later, I had to face the same choice with a different project. That loop exists as long as you keep choosing what you already know. Once I chose Angular, a few things happened: A, I learned angular (which is good for me), and B, the web app was much faster (which is good for the client). You can also add C, next time I won’t have to learn it again (which is good for future clients). Everybody wins.

9. Don’t be lazy.

Like the previous tip, this one requires not making the easier choice. When you work in a company where you know others will read your code, you try (I hope) to make your code more efficient and readable. But when working on a small project for a client, you have the temptation to just finish with it as quickly as possible, and not come back to the project ever again. Many freelancers do that, unfortunately, and I’ve seen horrible pieces of code written by developers who were simply lazy. But what you don’t know is that at some point, the client will want to change something, and another developer will have to read your code (or even worse — you!). At that point, you will either seem unprofessional, or (if you’re the lucky guy) you’ll want to erase everything and start from scratch.