Sometime last winter a friend was singing the praises of CodeKit. “It does everything you need,” he said. “It compiles Sass, minifies scripts. Give it a try.” So I did.

And yes, it does do a lot of things. It works as advertised. For $34, it’s a nice tool to have in the shed. For some projects, it’s easy enough to use it instead of the more developer-y process runners like Grunt or Gulp. No messing around with configuration files.

So I got lazy. I got in the habit of just letting CodeKit it do its thing.

But… (there’s always a but)

Over the last month or so it’s dawned on me that I was spending a lot of time configuring CodeKit for each new project to mesh with my workflow. I got to wondering if CodeKit was really saving me all the time and effort I had assumed it was.

It’s not that CodeKit is bad. For what it does, it’s really good! But my workflow requires handling files one way when I’m developing, then another way when I’m getting ready to deploy code. I’d have to customize CodeKit settings on a per-project basis for development, then re-customize to deploy, then set them back again when going back to development. And, doing all this back and forth customization by hand I found that missing one setting somewhere would often screw things up. Then I’d be going through everything yet again to figure out what I’d forgotten to change one way or another.

So this past week, I took most of a day’s work getting reacquainted with Gulp. So, let’s say that’s 6 hours of getting down into the nitty-gritty of it: the initial reinvestment.

By the end of the day I had a pretty decent working gulpfile that handles Sass compiling, script and style minimizing, and image compression – grabbing all the stuff I want, processing it how I want, and putting the results where I want. I’ll certainly tweak it again, but it’s a perfectly workable start and it’s customized to fit my workflow.

In the few days since I’ve started several new projects. With each of these, all I had to do was drop my package.json and gulpfile.js into the project, change the project name in the package, and run npm install. In under a minute, everything was ready to go, with development tasks and deployment tasks readily available and no worries about remembering which setting was where and in what state.

I’d go so far as to say that in the few days since, I’ve got 2 hours back out of the six I invested earlier in the week. By the end of next week I should break even on time invested.

Again, I want to emphasize that this isn’t a rant about CodeKit. I’m not complaining. I’ll still probably use it for some things here and there.

But here’s the thing. With CodeKit (and software like it), for $34 you can do a lot of cool things out of the gate. No need to put things on hold for a day while you work through building your gulp- or gruntfile. And if you don’t need a precise development workflow, it’s probably worth it. My friend who originally recommended CodeKit may never need to worry about customizing settings, and that’s ok.

The down side is that with CodeKit doing some cool things for you, you’re lulled into a sense that it’s saving time, when for more customized requirements it may actually be costing time. The risk is that you get lazy about thinking through your workflow, and (ironically enough) end up doing more work less well. That’s what happened to me.