Christian Naths, 780-231-4131, @christiannaths

Pricing My Services: An Open, Honest Answer.

Jan 7, 2015

Just the other day I received an email from a former student, looking to break out into the industry as a freelance web developer. He asked,

I recently started freelancing, however I seem to be having an issue with how much I should charge. I been researching , and the best method I found was charging hourly for small tasks projects and charging a fixed rate for large projects that are time consuming.

The only thing I'm concerned about is the pricing. Isn’t charging a $1000 a little too much for a starter. Please let me know. Give me your feed back, I would really appreciate it. Maybe this is new to me that I think it’s too much.

As a web design and development instructor, this is one of my most frequently asked questions, and it’s also a really difficult one for me to answer. Here was my response to him:


That’s a really hard question to answer because it depends on experience and skill. Here is what I do, maybe you can use that as at least a point of comparison.

I bill everything hourly at $85 per hour.

  1. I don’t like flat rates, because I find clients always want to push your limits (“let’s see just how much I can get for my $1000”). When they know they’re paying by the hour, they’re much happier to do only what they need, and they realize that my time is valuable so they don’t try to push their luck.
  2. I don’t change my rate for any reason. If a client wants me to attend a meeting, it’s $85 per hour. If a client wants me to write content, it’s $85 per hour. This helps clients utilize me for what I’m really good at: making websites. It steers them away from thinking, “Hey, get the web guy to do it as ‘part of the website build’, after all he’s just charging us a flat rate.” My only exception to my rate is when I’m contracting in-house for a company, for that I cut my rate in half (or at least start the negotiations there). I do this because the billable hours are usually higher and more stable, and a lot of the client interactions are handled by the company I’m contracting through.

The downfall to this system is that it makes it harder to do estimates. What I usually do is sit down and try to figure out approximately how long this project will take – usually, whatever number I come up with, I pad by about 50%. So if my thinking is, “Ok, this site should take me around 40 hours to code”, I write it down as 60 hours. Why? Because I suck at guessing how long things will take. I make it very clear in the estimate I send to the client that this is only an estimate, and the actual time it takes to complete the job could very well be different, but usually I manage to come in within 10 or 15% of my estimate. So if I think it’s going to cost about $5000 when all is said and done, then the client should be prepared to pay anywhere between $4000 and $6000. I like to estimate a bit high and then deliver in less time (and less cost to them), I find this impresses clients and they usually want to find ways to spend their remaining budget anyway. It’s a win/win for me.

I know what you’re thinking, “But Christian, $85 per hour is a ridiculous sum of money! You must be rich!” It seems that way, but you have to consider what it takes to produce a billable hour. There are emails to answer, estimates to write, books to keep, research to do. Not to mention those times when I am without a contract and not making any money at all. In a given month, I’ll be pretty happy to get 50 billable hours in, on average over the course of a year. Some months I’ll just crush it and be able to do over 100 hours, but there are definitely other months where I have no work and don’t bill but a few hours here and there.

Your hourly wage is far too low. I would suggest starting around the $35 to $40 and hour range, and see how things go. The more jobs you do, the quicker you get, and the more skill you acquire warrants giving yourself a raise. It’ll be hard at first and you won’t make much money, but with time I think this method really pays off.


Finally, a Sass project folder structure I actually like.

Nov 3, 2014

I've been working with Sass for quite some time; since about 2009 when it started to make a name for itself in the Rails community. It helps me write stylesheets more modularly, since its @import adds the code on pre-compile, rather than adding additional HTTP requests in the browser.

However, with the ability to break your code up into many separate files comes incresed complexity in your project structure: how do you keep it all organized? It's a problem that seems simple on the surface, but it's one I've struggled with pretty much since the beginning.

I think I've finally come to a nice, easy solution. In the current landscape of BEM, OOCSS, Atomic CSS, and SMACSS, it all can get a bit overwhelming. Having looked at all of these, I find OOCSS most attractive at it's core principles. The Github project itself is a huge turnoff in terms of complexity though, so I never really gave it a fair shake. It also doesn't seem to lend much in the way of file/folder structure.

Anyway, here's what I've landed on, in a project I'm currently working on. For the first time in quite a while, I'm pretty happy with how this is turning out.

figure 1
My assets/stylesheets directory


Things start off with a config directory. This is where I set up my document. Far-reaching changes occur here, like setting the document to use box-sizing: border-box and things of that nature. I also use this folder to store changes to elements on a micro-level. This is akin to an "atom" in Atomic CSS, but I've been using the term "base", since the rest of my CSS will inherit from it.

This directory also inevitably holds some setup files, such as a helpers file for my mixins, or a theme file which initializes some colour variables.


Here is where I create files for basic CSS elements. This is akin to a "block" in BEM. However, some elements may be just a single HTML tag: buttons are a good example of this, but I allow them to get more complex as well.


Layouts are styles for sets of structure only elements. They can have far-reaching consequences, so special HTML is usually written to accomodate for this. I'll generally have a "base" set of styles which the specific layouts inherit from. If the project is very simple, this folder can be substituted for a single "layout" file.


Views are location-based styles. Body classes are applied to facilitate styling elements differently in a particular view. For example, the "locations" page might need a full-width map, but the "events" page might only need a thumbnail. Both will use the same element with the same class name, but I can adjust the styles per-page using a view stylesheet.

That's pretty much the gist of it. Nothing too ground-breaking here, but hey, sometimes the simplest solutions work best :)


Some thoughts on mixing css floats

Nov 1, 2014

A collegue asked me a question about mixing the use of float:left and float:right yesterday, which I thought was interesting. He asked:

I've been living by the rule of "don't float in two directions" for years now, but I forget why, and I can't find justification on the internet. Why not float in both directions?

First off, you’re right. There is very little info about this online. The simplest answer I can give for this is: it ends up being problematic in the long run. If you are not confident you know what the width of your container (fixed/fluid width wrapper element) will be, it is just messy to work with, and when your floats “break”, it is difficult to understand why. Also, if you container is ends up wider than you think you will end up with gaps between your elements, which is usually not desired (even if it is desired, there’s a better way to accomplish that).

In a broader sense, the problem with this for me is the overall way of thinking. I prefer to think of my CSS structure as a tightly knit set of elements that simply holds content for me. I tell students to think of their grid as if the page were laying on it’s side, and the elements had weight. Floating left to every grid-type element reinforces that line of thinking. The internal dialog goes something like “float it left, float it left – oops no more room, next line…”, and so on. If suddenly you throw something in there that’s floated to the right it’s like that element is living in a different universe, with a different set of physics governing its behaviour. Like gravity suddenly works in reverse. It’s chaotic and difficult to manage.

I can’t count how many times I’ve helped one of my students with a broken float, only to find they have an element floated right amongst their left floated elements. All I’ve ever had to do in those cases is suggest they float everything left, and check their element widths. Nearly every time they’ve been able to solve their issue with only that advice.