Time is money, friend

Cushion, a SaaS for freelancers, has a transparent log of its running costs and expenses that recently got posted to HN and spun up a lot of positive discussion.

(This page has been around for at least a year, and I think it’s awesome – it’s what inspired me to similarly start tracking expenses for Village Blacksmith.)

One of the fairly common discussion points on the post was about how the accumulation of so many ‘small’ costs – in the $10-$50 a month range – can add up to such a substantial amount.

One commenter wrote:

This info is actually very useful for me as it confirms my (rational) fear of accumulating expenses. It’s way too easy to just spend $10-$50 here and there and before you know it you are spending $1000 a month, while the core service is still running on a single triad of web-server/worker-server/database-server combo with no redundancy.

To which another replied:

I literally use none of any such paid services. Zero. It’s really not that hard. Just automate what can be automated.

As someone who’s starting to accumulate these costs in the processing of spinning up ‘legitimate’ businesses, I don’t love this line of thinking.

It’s true that a lot of common paid services can be spun up by a developer rather than vended as a SaaS. I’m talking about things like:

None of these are particularly technically challenging, on the surface. They’re definitely not trivial to implement, but there are no prohibitively complex barriers that stops a developer from rolling their own solution to the problem.

So why shouldn’t you create your own solution to these problems?

Hell, I’ll take the simplest example I can think of: BriefMetrics, a simple (and lovely) service I use that sends me weekly digests of Google Analytics data. The data isn’t subject to any complex analysis or munging: it just saves me the effort of having to dive into the labyrinthine Google Analytics dashboard to grab the data I care about.

Two notes about the cost of this service:

So why haven’t I written my own version of it, and lowered my expenses?

I know I could spend maybe two hours 1 writing a replacement for it and set it on an EC2 host and probably never worry about it again.

I value my time at $200 an hour. (In fact, I value my time a little more than this, but $200 is a nice round number and it’s roughly my consulting rate). That means the two hours I spend costs me $400 in labor.

This brings me to a straightforward decision, right? If I think I’m going to use this for more than three years I should just spin it up myself – the investment in time ($400) will pay for itself over the long haul end up being cheaper than me shelling out for the service each month ($360 for three years).

Except that’s not counting all of the other little pieces:

If there’s one thing that I’ve learned as a developer, there’s no such thing as a true one-time-fee when it comes to development: everything carries technical debt, and you’re going to have to hit it sooner or later.

So I let BriefMetrics handle everything there. Maybe, at some point down the line, my needs will change or the price will increase and the calculus will work out differently.

But my engineering time is sacred – I want to spend it as smartly as possible, and if I can save a couple hours by coughing up a paltry monthly sum, I will. There are bigger fish to fry.

Truth be told, I feel like I’m the type of person who wants to roll my own dependencies most of the time. Building stuff is fun, and the endorphin rush of completing a component that saves me a monthly bill is great.

But it’s rarely the responsible thing to do with my time.

And I figure if I’m ever in a position where implementing away a $19/month expense is the best use of my time, then something’s wrong, you know what I mean?

  1. And, knowing Google’s APIs, this is a tremendously optimistic estimate. [return]
Subscribe to my newsletter to be notified when I post something new (every few weeks):

Justin Duke is a writer and developer in Seattle.
He likes good, practical things.
(And writing in the third person, I guess.)