In the past when I’ve worked on side projects it’s been primarily on nights and weekends. Between school and work, I never had time for them during the day and because I’m not much of a morning person, nights and weekends always worked better.

When my son was born about three years ago, a lot of the time that I would have put into side projects went towards trying to be a good dad to him and now also to my daughter. This led to less time during the week because after I would get done with work, I would spend time with them and after they would go to sleep, I wanted to spend time with my wife and relax. I also can’t stay up too late because I needed to get up with the kids in the morning. Similar story on weekends.

This has led to my side projects time dropping from maybe 10-15 hours/week to only 3-4 hours/week for the last several years.

Inspired by my friend and coworker Dave Martin, I’ve started experimenting with waking up early to work on side projects. Not 4am-5am like him (!), but just at 6am. That gives me 1 to 1.5 hours to focus on side projects most days. I take Saturday off and also wind up skipping some other days, but it’s probably doubled the amount of time I put into side projects to around 7-8 hours per week.

To make this work, I’ve also had to adjust my evening routine. Instead of going to bed around 10:30pm, I try to be in bed by around 9:30pm to make sure I get in 8-9 hours. I wind up watching less Netflix, but don’t feel like I’m missing anything important.

And as a side effect, I’ve found that I’m sleeping a lot better now that I’m no longer jumping straight from coding into bed a lot of nights. All too often I’d just lie there for hours waiting for problem solving mode to turn off. Now I read and it makes it much easier to fall asleep.

If you typically work on side projects at night like I did in the past, I encourage you to experiment with waking up and going to bed early for a few weeks to see how it works for you.

At Automattic and now at Help Scout I’ve been involved in several discussions about the merits of building something internally vs paying for a third party SaaS tool or plugin. Examples include the internal analytics platform Automattic (which we wound up building ourselves) and a business intelligence tool at Help Scout (which we wound up buying).

If you’re lucky it will be an easy decision, but more often than not there will be pros and cons to both approaches that you’ll have to weigh. Some of the factors include:

Do you have the engineering resources and know-how to build it? If not, you’ll obviously have to buy.

How much time will it take to build? As anyone who has built software knows, estimating how much time it will take to “complete” is often incredibly difficult. A one month project could easily turn into four after all is said and done. The more complex the project and the longer it will take to build, the more you should lean towards buying.

How much does it cost to buy? The cheaper it is the more it makes sense to buy.

How much will it cost to build? At first this might seem like $0, but engineers are expensive. A developer making $120K/year might be $180K/year fully loaded (with benefits, taxes, etc) or $15K/month. Several developers spending a month on a project can easily cost tens of thousands of dollars. And that’s not even counting PMs, designers, and anyone else involved in the project. It’s tempting to think “we have to pay them anyway so it doesn’t really cost us that”, but it’s not so simple once you consider what other revenue-generating projects they could be working on instead (and you don’t have to employ them anyway). There’s a real opportunity cost to building something internally.

Does the thing you’ll buy meet all of your requirements? If it’s critical that the software do something and the SaaS you’re considering doesn’t do it, you’ll probably need to build. However, you might be better off paying for a tool that is 90% of what you think you need vs spending weeks or months building something that might be 100%.

What other capabilities does the tool you’ll buy provide? While you might be able to build something that meets your minumum requirements, a tool you buy is likely going to do a lot more than the minimum. You may not think you need those extra features now, but there’s a good chance that you will later. At that point you might have little choice but to keep iterating on what you’ve built which can easily extend the duration of a project.

Is it important to own the data? Third party tools will likely collect user data which may be a concern both from privacy and analysis perspectives.

How likely is it that the third party solution will exist in 5 years? And are there alternatives you could switch to if that hot-new-startup you pay for shuts their doors in six months?

Are you building this as a long term investment? When we were considering whether to buy or build Automattic’s internal analytics platform one of the factors was that we planned on Automattic existing in 10, 20+ years so it made sense to invest time building something that we could use for the long haul. Be skeptical with this one though: while we might hope that whatever we’re working on now will exist in 20 years, the reality is that it probably won’t.

I usually default to buy unless there is a compelling reason to build. In my experience software usually takes much longer to build than initially expected so it winds up making more sense to pay for a 90% solution that you can have immediately and devote those engineering resources to the core business. But again, it’s often not so simple in practice and there can be reasons to build instead (full control over the features and design, ownership of the data, cost, etc).

I’d love to hear about your experience buying vs building. Was there ever a time you built something that you later regretted or vice versa?