By James Steinbach

Passing Your Sass to Someone Sass-less

By James Steinbach

Sass is like Pringles: once you pop, you can’t stop. After using Sass for a couple projects, picking up a vanilla CSS project feels weird. “Where are my variables?” “Why can’t I nest things?” “I just want this one mixin…” In all of our Sass-isfaction, it’s actually pretty easy to forget that there developers out there who don’t or can’t use a preprocessor. And we shouldn’t forget them or disparage them!

There are plenty of situations where you might hand off a site to someone who doesn’t use a preprocessor. Some developers are freshly starting CSS and nailing down that core knowledge. Some love the ideals and simplicity of CSS and feel that a preprocessor adds needless bloat to their workflow. Others maybe working with a limited set of tools and don’t have the ability to run a preprocessor where they need to. I’m not saying these are all ideal or perfect situations, but each one has a measure of validity.

If you’re going to develop in Sass, you may need to have a game plan for how you’ll hand it off to a Sass-less developer. Let’s look at how this process normally happens and try to identify the best way for you to make your end of this hand-off as smooth as possible.

Just hand them the code and walk away.

This is probably the default: we just pass along the code to whoever is going to maintain it and hope for the best. Unfortunately, this may also be the least helpful method.

What happens when we give a client or site manager a folder full of Sass partials and no instructions? I don’t have any empirical evidence to support this statistic, but I’d bet that nine times out of ten, the /sass/ directory is ignored and all changes are made to the compiled CSS. Is that a problem? Well, if you compressed your output, yeah. Good luck to even an experienced CSS author making edits to a compressed style sheet!

If you’re going to deliver code without any preprocessor instructions, you should be prepared to deal with all the client’s edits if they ever ask you to do more work on the site in the future. Be ready to move all their edits back to Sass and resume your workflow, or simply edit the CSS. If there’s even the slightest chance someone will want to use a preprocessor on the site again, I recommend giving the client a quick explanation of your set-up and a warning that any changes they make to the compiled CSS are in danger of being overwritten if a future developer is careless about returning to Sass.

Only deliver the compiled CSS.

If you know that no one will ever use your Sass files again, I wouldn’t bother including them in the deliverables. In some cases, I would also recommend delivering an unminified style sheet for the sake of simpler maintenance. I know this is a performance hit: if that concerns you, talk the client through the pros and cons of performance vs. maintainability and let them take responsibility for the decision. If you’ve got a caching / minifying / concatenation performance tool set up for the delivered site (WP plugin, web service, etc), this is a moot point. Just give them the unminified CSS, let them edit it happily, and let the performance tool handle the minification.

Give them a separate “edits.css” style sheet to put changes in.

I don’t like this idea much. Performance takes a hit because you’re adding another request to the render-blocking critical path. Also, this method accidentally encourages over-specificity. Not everyone understands that later CSS overrides prior CSS if the selectors have the same specificity (I guess for those people, it’s just SS, not CSS?) Someone like that will be prone to filling their edits.css file with !important declarations and unnecessary IDs.

If, however, you’re handing off to a skilled CSS maintainer and they’re comfortable with the slight performance hit (or using a minifying/concatenation plugin to negate it), this is a great way to keep all the edits in one place and keep the original Sass pristine for a future developer.

Teach them how to use a preprocessor.

I can hear you laughing from here. Stop for a minute and let me explain! I know this won’t work for every client. There are some for whom this method would be a disaster. You know who I mean: there are the “I know a little CSS” folks, and also the people who are so thinly spread doing a hundred things for their start-up or business or side project that they don’t have the bandwidth to learn Sass.

But if you have a client who can handle learning a new step, I would offer to train them to use the Sass partials you’ve set up. This will require an investment of your time and theirs. (If I were doing an “intro to Sass” training session with a client like this, I’d bet on at least a half day, probably a full day.)

Remember, you’re a professional and you should be paid for this time. If you can sell it to your client as an add-on toward the end, more power to you. On the other hand, if you think the client would do really well with this training but would not pay extra for it, add the cost of your training day into the site package cost & throw this in “for free” at the end.


Handing off Sass files to non-Sass site owners and maintainers sure isn’t the easiest thing to do. With some planning ahead, however, it can be successful. Please leave comments with other ways to manage this hand off or stories of how one of these methods has worked for you!

  • Todd Zmijewski

    The most difficult part of teaching someone to use sass has been environment set-up in my experience. Many people who are not familiar with the command line are put of my the tedious and somewhat stressful process of installing ruby/rvm and all the sass dependencies for projects. Though it depends on the type of machine the person is running. This is one reason I’m a proponent of EVERYONE using vagrant. All this stuff is just so easy to set-up on a true linux vm and eventually you will run into it.

    • And if you can’t get the new devs onto Vagrant, an app like Compass, Prepros, Scout, etc, is a great way to give them a GUI compiler. I know, not quite as “pure” as CLI, etc, but a good tool for newcomers.

  • i will be very grateful to you if you can write an article “how to use sass in your project for beginner” because the documentation is not understandable which is provided at I already use less and installed sass with ruby but I really don’t know how to get start with it in my next project.

  • Jani Hartikainen

    I’m not sure why you would use SASS in the first place if you have to pass it to someone who doesn’t understand it. Seems like a poor idea to me. It’s the same thing as with any other lang, you wouldn’t use it if you know you need to pass it to someone who can’t use it and has no intention to learn.

    (of course if it comes as a surprise at some point along the way, then it’s a different matter)

    • Having run workshops on Sass, front-end’ed for several clients, and spoken to many developers over the last 12 months or so. The question of handing over something written in Sass to someone that doesn’t use Sass comes up a lot more than you think.

      • Jani Hartikainen

        I’m sure it does – that’s why this article exists. But the question was WHY would you use Sass if you know you’ll need to pass the result to someone who doesn’t know it?

        • Why should an organisation, like a University, not use something like Sass if they’re developing in-house and 80% of their out-sourced developers use it. Should they cater for that 20% only? That seems illogical.

          • Jani Hartikainen

            It depends on how much impact the 20% would have. If you can leave fiddling with Sass to the 80%, then no problem, but if the 20% would be doing most of the heavy lifting and can’t/won’t learn Sass, then the tech mismatch would seem like a bit of a problem.

    • Jon Gellart

      Your client has a website on WordPress and you are contracted to create a new theme for it. You will pass on the theme to the client when you are done and the client does not know PHP. So would you still make the theme in PHP?

  • StNick

    I love Sass but it took me a while to master. Why? Because once you set things up, it really isn’t that difficult. Personally, I feel documentation could be better. Like Todd Zmijewski, I encountered similar problems and had so many errors encounters in setting up my workflow due to administrative rights and system paths that I would get stuck halfway, without anyone to help. After discovering I had to reinstall everything as an administrator and mastering the system path, finally everything went a smoother. Still, this took me at least a few months and a lot of frustration.

  • I tend to include as much guidance on the setup and workflow as possible in a file in the root of the project. This includes explanation of the source and compiled SASS. I then also add a note suggesting that non-SASSers could put CSS edits at the bottom of a duplicate of the compiled SASS and reference this in the theme instead of the original (e.g. style.min.css -> style.edited.min.css).

    Far from ideal, and a tricky one to answer, but the above is simply what I choose to do at this time.

    The handover and future is only as good as the guidance AND a client’s willingness to actually read it!

  • Debbie Campbell

    I’ve started using Sass in the last 4 months and love it. I’ve had to pass off a few projects to clients and none of them will ever touch the CSS (they would have no clue what that even meant). But occasionally I do have a client that may edit the styles, and for them, I’ll probably just provide an un-minified version of the stylesheet. Teaching someone with very little CSS skill Sass is definitely not something I’m inclined to try…

    I am working on a project right now for another designer, who edited style.css over the weekend and didn’t tell me. When I started working and recompiled it on Monday morning, she was upset that her changes were gone. I explained that I was using Sass and how it basically worked, and she said she’d just stay out until I hand off the project. For that client, for whom I do a lot of work, I would happily explain the basics of Sass and she’d likely get it, but I don’t think she’d be interested enough to get a compiler, etc. For her, I’d also provide an un-minified stylesheet along with the minified one; she’d understand the reason for minification and showing her how to do it would be pretty easy.

Get the latest in Front-end, once a week, for free.