Tips for Project/ Flat Rate Invoicing

Tips for Project or Flat Rate Invoicing
I recently had a question come my way from a new freelancer about pricing client work. She’d already created a draft invoice for the work and was looking for feedback on whether she was pricing appropriately and thinking comprehensively about the work.

While I didn’t provide her with feedback on her specific pricing, I did send some quick thoughts on the way she was itemizing the tasks and describing the scope of the project and thought they’d be worth sharing here for others who might have similar questions.

She had her invoice itemized out something like this:

Service Time Cost
Domain & Hosting Setup; WordPress Install* A hrs at $X/hour $YYY
Theme Research & Installation, Minor Customization B hrs at $X/hour $YYY
Content Entry (5+ Pages, Multiple Image Galleries) C hrs at $X/hour $YYY
*Cost of domain registration, hosting, and WordPress theme not included

The Good Stuff

There are a lot of good things about the way this is set up already!

Itemized Services

I was happy to see this person listing out various components of the service they’re providing the client, breaking things out into groups of similar tasks. This really helps clients understand what they’re paying for and also makes sure everyone is on the same page regarding project scope.

Research Time Included

It’s also great that she included research into themes as part of the project scope, since in this particular project she was helping the client find a suitable pre-made WordPress theme to use. It takes time to match up client requirements to available themes and that time should be accounted for and clearly delineated in the invoice or estimate.

License and Recurring Costs Not Included

I was also very happy to see that she had specifically noted that recurring costs (hosting, domain registration) and the cost of the theme are not included in the quoted total. I feel pretty strongly about not including those types of costs in base invoices and instead having the client have ownership over their accounts and pay the actual cost of whatever licenses are needed so that they have those things in their name.

I also usually note in my invoices that web font license costs aren’t included, as that’s another semi-hidden cost that the client should be aware of from the outset and that I won’t cover myself.

Areas for Improvement

While the info this freelancer included was a great start, there are also some definite areas for improvement and further specificity.

In fact, my general rule with estimates and invoices is to be as specific as possible and also to note that things that aren’t listed aren’t included. This helps protect me against scope creep and also makes sure the client knows they should ask early on in the process if they’re looking for something specific that isn’t listed on the estimate.

In this example, I had three suggestions for things to improve on.

Avoid Relative Terms

The phrase “minor customization” raised a big flag for me, as it’s unclear what “minor” would include. A lot of the time, things a client may think are “minor” actually aren’t as straightforward as they may seem, so it’s best not to use relative or subjective terms and instead be really clear about what you’re going to customize and what the limits are. I might specify “customization of colors, fonts, and header graphics” or something like that.

Include Hard Limits

I was also concerned by content uploading including “10+ pages” and “multiple” image galleries. This is another place where you want to be really specific and provide caps rather than minimums or general terms (“up to X pages” and “up to X galleries with up to X images each). Otherwise you are going to end up hating life when you’re uploading image 125 of 160 on your 15th gallery page.

Overage Plan

While I don’t actually include this in my estimates and invoices (it’s in my contract instead), I also prompted this freelancer to consider what she would do if she went over the hours she listed or if the client needed more than outlined in the project scope.

I don’t include hour indications in my estimates unless it’s a line item specifically for hourly work, as the hours are irrelevant to the client when I’m really quoting on a project or output basis. If I go over my predicted hours getting to the agreed-upon scope, that’s on me and it doesn’t change the quote for the client.

On the flip side, if the client ends up wanting more than what we agreed upon, it’s good to be clear about how you handle that. For me, I say that I’m ok with adding to scope but the client has to know that that increases the cost of the project and may also impact the time frame.

Overall, this freelancer was starting from a good place with her invoices and just needed a few small changes to make things more clear and concrete for both parties, which ensures a much smoother process overall.

Six Ways to Make Your Developer Happy to Open Your Files

Six Ways to Make Your Files Developer-Friendly
Working with many different designers can be tricky in that the file structures and organization tends to vary from person to person. Fortunately, most of the designers I work with prioritize creating well-organized, highly usable files, which makes my job of taking those files and translating them into code much easier.

Even still, there are a few things that I see happen with designers that are less familiar with designing for the web that make a huge difference to the developer who takes over their files. Here are my top six suggestions for things you, as a designer, can prioritize in your files to make for very happy developer.

1. Organize Your Layers

It is impossible to overstate how important well organized layers and groups of layers are to both my workflow and my sanity. I need to be able to turn layers and groups of layers on and off to get at various components of the design (check out my video on slicing for more on how that works).

Also, if I’m trying to get at a piece of information in the file, it is next to impossible if I’m looking at a mess of layers that haven’t been named coherently and haven’t been grouped at all. Even worse if they’re flattened and I’m unable to get at a single component or get into the text to see the formatting!

I love the Photoshop Etiquette site’s tips on layers (really, everything over there is good advice).

2. Use Full Pixels

This one comes up more often with Illustrator than with Photoshop, but it’s important in both. The web is a pixel grid, so the design needs to respect that and use full pixels for all elements including font sizes. Half pixel values just don’t work, and if you use them your developer will be forced to adjust and round and otherwise tweak your design.

Along the same lines, people who are used to working in print sometimes have issues with scale and resolution. It’s important that your files be the correct actual size, again so that your developer isn’t forced to do the conversions and potentially face related issues with the design. When designing for the web, use 72 dpi and pay attention to the pixel dimensions.

3. Use Fonts with Web Licenses

Talk to the client early and often about licensing! It’s unfortunate for everyone involved if we have to have the first conversation about licensing when we’re ready to start development, particularly if the news isn’t good (e.g. particular font license is very expensive, or maybe not even available).

This has become less of an issue as web fonts have become more common, but I still see designers use fonts that aren’t available for web, or use fonts that are available but with a cost that the client doesn’t know about. There are great alternatives for many fonts if the client is budget-conscious and it’s better for everyone if you decide what the font plan is early on rather than trying to swap out fonts after the design is approved (it’ll never be quite the same).

For more on web fonts, check out my comprehensive Learn Web Fonts resource page.

4. Use a Grid – Any Grid

Along with using whole pixel values, it’s helpful if a design is based around a grid system (and if all elements are snapped to the grid, or at least mindfully placed to break the grid). I really don’t have a preference as to which grid system each designer uses, and in fact I think it may well need to vary from site to site based on the design plan for the project.

That said, using any grid system will ensure a more consistent, precisely aligned, and easy to measure and code site.

Tuts+ has a nice introduction to grid systems to get you started if they’re new to you.

5. Be Consistent

Again, these are very connected concepts – consistency is helped along quite a bit by using whole pixel values and grid systems, for example. However, consistency also goes beyond those things. When I think of consistency in web design, I think of things like having a plan for the typography across the site such that you can come up with a coherent style guide:

style guide sample

Ideally, your style guide should include all the various HTML text styling options, including:

  • regular body text
  • italics
  • bolded text
  • heading styles for heading levels 1-6
  • blockquotes
  • lists (although if you can avoid fancy contrasting numbers and bullets that makes things easier)
  • links and link hovers
  • buttons
  • form fields

Where possible, it’s nice to be consistent in your use of fonts, sizes, and styling across the site both because it makes the coding easier but also because it presents a consistent visual hierarchy to the viewer. If you want to break the pattern, do it intentionally and in such a way that you can point it out as a non-pattern to the developer.

Similarly, consistency in spacing between and around elements can be helpful (and again, grids are your friend for this).

6. Provide Static Comps

I’ve only recently started asking designers for static comps for each page and view of a site after having a couple of designers provide them and realizing that they are extremely helpful. By “static comp,” I mean a snapshot of the design that isn’t impacted by layer or group visibility, font application, and other things that can be altered accidentally in Photoshop.

There are two main methods I’ve seen for providing these comps, either of which work for me:

JPG Image Grabs

A couple of the designers I work with provide me with neatly organized and titled JPGs of each page layout along with additional images showing key hover states or interaction points. At first I wasn’t sure if this really provided additional benefit but I’ve found it to be really helpful for two things:

1. Ensuring We’re Seeing the Same Thing

I spend a lot of time turning layers on and off for slicing purposes and messing with type to get the specific styling information, which can throw off the way the file looks in Photoshop. The risks here are mitigated with well-organized files where unnecessary layers have been completely removed before the files are sent to me, but even still having a static, non-editable reference image is a nice way to cross-check and make sure the view I have is the same one the designer and client have approved for development.

2. Checking Our Work

Photoshop can be a cumbersome program to work with, so especially when we’re at the testing and wrap up phases of a project it can be much nicer to whip open a clean JPG and compare that with the live site. When we just need to check a font style or the placement of a sidebar widget, JPGs are the way to go.

Layer Comps

The layer comp Photoshop feature kind of sneaks up on you. It comes across as vaguely interesting at first, but once you’ve used it a few times you suddenly realize how insanely helpful and magical it really is.

The general idea is that you can create a variety of layer comps within a Photoshop file where each is a snapshot in time of your file, including the placement and visibility of various elements.

One designer that I work uses layer comps to demonstrate hover effects for various areas of the site, meaning she’ll have one layer comp showing the non-hovered page, one showing the header hovers, one showing the content hovers, and another showing the footer hovers.

Another use case for layer comps could be showing different states of a module, for example using different layer comps for the standard and sale displays of a product in an e-commerce site.

For a quick, basic tutorial on Layer Comps, check out this video on the Adobe site. However please don’t name your layer comps the way they demonstrate!

I’m sure there are many many features of great files that I’m missing, but these are the top things that come to mind when I think about what I really like to see in a design file.

Q&A: Subcontracting as a Way to Build Skills

Q&A: Subcontracting to Build Skills
A recent email asked about subcontracting as a way to gain more experience as a newer developer:

I’m not a designer, nor I am a developer at the height of my power yet, however I’ve made a lot of progress and I feel I can help more senior developers, while I learn more to tackle larger projects on my own. [I’ve been thinking] that maybe I could focus on assisting other designers and developers. What kind of help do you, as a lead developer, look for?

Huge caveat: I have only ever worked as a self-employed developer, so my context is pretty limited.

That said, I have a bunch of thoughts on subcontracting in general, and also why it’s probably going to be pretty hard to find subcontracting work that will really build skill in development when you don’t yet feel comfortable tackling full projects.

Subcontractors vs. Employees

One big issue around the legal concept of subcontracting (at least here in the U.S.) has to do with the types of tasks and oversight the individual is taking on. I insist on a really high level of control – while I don’t want to micromanage every step, I do want to be able to give pretty strong guidance on how things should be done. For me, this works out to needing to do most of the work delegation via an employee relationship.

I also find that it’s hard to break out smaller parts of my projects such that someone else can work on them unless that person is already familiar with my processes, systems, theme structures, etc., which typically is just not realistic for subcontractors.

Commonly Delegated Tasks

That said, here are a few things that I often delegate and/or would consider subcontracting to a good external developer:

Browser Testing

This is a big one, I really don’t like clicking through a site I’ve built a million times in various devices and browsers. I’ve found that testing usually goes better for me when someone else does thorough tests of ready-to-launch sites and then sends me a “fix list” with screenshots. Usually one of my associate developers does this.

Site Installation & Setup

With WordPress, there’s often some initial installation and setup, including everything from installing WordPress itself to creating pages, setting up menus, and putting widgets in place. With Shopify, there’s no installation but there’s a lot of product and page creation, even when just working with dummy content. Later in Shopify projects, there’s also some manual setup with shipping rates, email templates, and similar admin settings.

All of these admin tasks are fairly easy to delegate, although the timing can be tricky as it requires pre-planning to schedule this work at the right time in an overall project schedule.

Changes to Existing Sites

I don’t take on any projects making modifications to third party themes. The only changes/ “tweaks” projects I work on are updates or modifications to themes I created. When these types of requests come in they’re often things I consider delegating, particularly if they don’t require a ton of context and/or are fairly straightforward.

Content Work

Another common subset of requests I get revolve around content updates or supporting clients in working with their client. Some clients prefer to have someone else handle content updates and edits, no matter how nicely we’ve set up the admin of their site, and others would prefer to outsource image editing and optimization tasks. This is an area where I absolutely delegate the work to employees and subcontractors.

Issues to Consider

Unfortunately, the above set of tasks probably don’t strike you as the most exciting things in the world. I just haven’t found any good structures for breaking up the more development-centric parts of projects, although it’s something I always have in the back of my mind so maybe that’ll change.

Beyond the types of projects that can be subcontracted, there are a couple other barriers worth mentioning:


A big factor for subcontracting is cost. I obviously need to make a profit, so I can only subcontract work if I’m able to do it for less than it would cost for me to do it myself. That calculation has to take into account communication and paperwork with both the client and the subcontractor, project management (even with small tasks), etc.


As mentioned under cost, sometimes it just takes too long to handle finding and contracting someone else to do small tasks. It ends up being more effective to just knock them out in-house.

I also usually don’t have schedules planned out for individual projects such that I can give much advance notice for these types of tasks, which would make it hard to schedule with a third party.

The Good News

All the caveats and challenges above notwithstanding, I’ve found a few subcontractors lately who have managed to fit into my workflow swimmingly. For me, the most important factors for whether I’ll actually follow through with a subcontractor are very similar to the factors I look for when hiring employees, namely communication skills and attention to detail. With subcontractors I also make sure I am very confident that their quality of work will meet my needs without a lot of management, given that management is explicitly not part of a subcontractor relationship.

Bottom Line Advice

My best advice for people interested in building subcontractor relationships would be to think up front about what you can offer (skills, tasks, etc.) and then send a friendly, concise, well-written introductory email that includes the following:

  • What you’re specifically interested in helping with, large and small (especially small and/or “non-glamorous” tasks that you’d be willing to tackle to get in the door)
  • Your general availability/ turnaround time frames including how much notice you’d need
  • If you have a hard line on pricing, include that, otherwise leave it open to discussion
  • Links to examples of your work that you are especially proud of, or other specifics that show you can do the job well

I think it never hurts to reach out and ask!

Introducing Emi, a Gulp and Sass-ready WordPress Starter Theme

Hey, did you know that April is Autism Awareness Month? It’s true! One of my kids is autistic, and since autism occurs in approximately 1 in 68 individuals you probably also know someone with autism. If you’d like to learn more about what autism is, I recommend this description. The Thinking Person’s Guide to Autism is another great resource.

Now, on to Emi…

Emi WordPress Starter Theme

I recently quietly made the repo for Emi, my WordPress Starter Theme available to the public, but it’s about time I actually announced the release.

Emi is a true starter theme – it’s got a foundational set of files and codes to jump start theme development, but it is not meant to be used as-is. It isn’t meant to be used with child themes, either. Instead, Emi should be directly edited and modified for custom theme projects.


Emi comes with a few features built-in. Note that these features may not be for everyone, but they’re in there since they are what we use in our workflow. While I’m happy to be making Emi public so others can use it, modify it, etc., at root it’s still a tool that I use regularly and so the feature set is specific to how I use it.

Template Files

Emi’s got the template files that I use most often, including:

  • 503.php, to be used with the Maintenance Mode plugin as a landing page during active development (tutorial here)
  • archive.php, with code for archive-specific page titles
  • functions.php, with some useful theme options enabled and some starter snippets for other common customizations
  • Page templates for full width layouts and two kinds of redirects

Folder Structure

We’re constantly revising and rethinking our folder structure based on best practices and what makes sense for our purposes, and I’m pretty happy with what we’ve got now. Most of the template files are in the main directory.

We’ve split out the Sass files in their own /scss/ directory, which has some additional directories for custom page styling and blog styling.

There’s also an /inc/ directory for modules or pieces of code, and a subdirectory at /inc/functions/ for modules that are specific to the functions.php file.

Finally, there’s an /assets/ directory that contains theme javascript and subdirectories for images and for any vendor files we add to the theme (e.g. jQuery plugins).


The template files have been updated to use HTML5, with HTML5 Shiv to help out older browsers.


Emi uses Sass to make CSS authoring both easier and more powerful. The main actual Sass features in use are the file structure/ partials, variables, and nesting.

You’ll find the variable definitions in /scss/_base.scss and a few starter mixins (including a sticky footer and HTML5 input support) in /scss/_mixins.scss. All the partials are combined in /scss/style.scss.

We use Autoprefixer to automatically add all the necessary browser prefixes to newer CSS features, which is part of the Gulp task for processing our Sass.


We’ve integrated Gulp into our theme work (we also tried Grunt but found Gulp to be much faster), so it’s integrated into Emi as well. Gulp is a task runner, and the gulpfile.js file in Emi is set up with the tasks we use in our workflow:

Sass Processing
The gulp styles task processes the Sass files and also runs Autoprefixer before spitting out the minified CSS into the theme’s main style.css file.

Image Compression
The gulp images task compresses images from the /assets/images/originals/ directory, spitting the compressed files into the main /assets/images/ directory.

Watch Task
Finally, the gulp watch task runs continuously, watching for new images or changes to the Sass files and triggering the appropropriate task automatically. It also is hooked up with LiveReload.

You can download Emi from GitHub, and it’s under an M.I.T. license so you’re welcome to do with it what you will.

We’re constantly tweaking and improving it and would love your help! You can submit bugs or suggestions for improvements via the GitHub issues tracker, and feel free to send pull requests if you fix any open issues.

Twitter Strategy Tip: Images vs. Twitter Cards

Last week when I was hopped up on sinus medicine I mostly stayed away from blogging and social media, in part because all I did outside of client work was try to keep up with my children and sleep, and in part because I was a little worried my normal filter wouldn’t be working at full capacity.

I think I probably proved that second reason true with the comments I left on this Shopify blog post about Twitter Cards pointing out that the examples in the post actually mostly don’t show Twitter Cards and instead are just photos attached to tweets.

While I still feel kind of bad for pointing out something seemingly so trivial, I’m ok with how I did it and upon non-medicated reflection it still does bother me a little bit that the examples are wrong, mainly because (a) accuracy and (b) there are strategic reasons when using a photo makes sense and strategic reasons for using Twitter Cards and they’re for different purposes, at least in my book.

So in an effort to make usefulness out of grumpiness, I thought I’d explain why I use both techniques, and why I consider them two different sides of a similar strategic coin.

Twitter Tip: Photos vs. Twitter Cards

Why Use Twitter Images?

According to this Mashable article (and I believe it, from my own Twitter usage), including an image in a tweet dramatically increases share rates. Not only do images tell the viewer more about the content of the tweet, but they are very eye-grabbing given that they’re partially expanded in the timeline in the desktop app and some other Twitter clients.

Twitter Cards, which usually include both an image and some kind of text, are created on the site side via meta tags in the markup, so you don’t have any control over whether a link you share from someone else’s site supports them. From my unscientific research looking through my Twitter feed, most sites (even many you’d expect to be on top of this type of thing) do not support Twitter Cards. A quick way to check is to view that site’s own Twitter feed, as you’ll probably find links to their own content in their tweets.

Images, however, are completely within your control, since you can just upload them directly to the tweet using Twitter’s built-in tools. As such, when sharing third-party links, unless you’re certain there is Twitter Card support, it’s a good idea to include an image manually.

I do this a lot with various resources I share, using quick screenshots I’ve grabbed from the linked site, e.g.:

Why Use Twitter Cards?

As mentioned, Twitter Cards are content summaries, often with images, that you can set up for your own site by adding some simple markup. There are a few different types of Twitter Cards, including a “large image” card that looks similar in many ways to a tweet with a photo uploaded, and “gallery” cards, which show multiple images.

Here’s an example, although currently you don’t get the full effect of the large image via embedded tweets so you may want to click through to see the tweet on Twitter:

The benefits to using Twitter Cards over tweets with photos are:

  1. If you set up Twitter Cards for your site, every link to your site will automatically have them, even if the person tweeting the link doesn’t bother with images (which is most people tweeting your links)
  2. The Twitter Card is generated from the regular link URL, so you don’t need to have both a link URL and a photo URL hogging characters in order to show a photo and direct people to your site
  3. Twitter Cards provide even more information about the content, usually including both title and a short excerpt along with the image.
  4. There are multiple kinds of Twitter Cards for different purposes, including the aforementioned multi-image gallery cards and even video cards.

So, in my opinion it makes sense to implement Twitter Cards for your own site and then you’ll default to using them when you share your own content. As a wonderful bonus, everybody else who shares your content will have their tweet’s share-ability boosted via the extra content in the cards.

When you don’t have control over the link’s content, then it makes sense to use an uploaded image instead.

Further Thoughts

Of course I can’t leave at just the baseline explanation, so here are a few more related thoughts on Twitter images and Twitter Cards:

Images for Every Tweet?

Just to clarify, I don’t think you have to use an image or Twitter Card for every single tweet. One of the things I like about Twitter (compared to Facebook, for example), is that it’s very text-focused and requires more thought put into words than I see in much of the rest of the internet.

For some types of content sharing, images are really a useful way to both help readers understand what it is you’re linking to, and to encourage further sharing – that’s when these techniques come into play.

What happens if you use both?

I couldn’t find documentation outlining what happens if you post a Twitter Card-enabled URL along with an uploaded, but never fear, I tested it out. It turns out that the uploaded image has priority over the Twitter Card display. In retrospect, this seems obvious, so nicely done Twitter.

A Twitter Cards Tutorial

If you’ve made it this far and are like, “SOLD, now how do I do it?” then you will be pleased to know that I’ve got a tutorial on setting up Twitter Cards ready and waiting for you. Go forth an increase share-ability!