A lot of stories about building and wishing you had bought. I'm going to go the other direction. I have a story of buying something that was later scrapped and brought in-house.
I started blogging in earnest in 2005. At the time, I thought building my own blogging tool would be too much work, so I looked around for options that would allow me to store my content locally in source control. I settled on Blosxom, a Perl-based tool. Static site generators weren't really a thing in 2005, or I probably would have gone with that.
Blosxom served me well for 15 years, but it had problems. It ran on Apache, and every time I upgraded MacOS, I had to fiddle with Apache config to get it working again. It was customized with various plugins, and over the years I accumulated a lot of plugins and tweaks, to the point where I was afraid of making changes for fear of inadvertently breaking something. And it was very slow. I have a huge amount of content—I just checked, and it's currently at 6.9MB of text—and Blosxom couldn't handle the volume.
These problems meant that I eventually got to the point where I couldn't realistically make changes to the website any more. Blosxom had to be replaced.
Let's set that story aside for a moment. Back in 2012, I started a subscription-based screencast called "Let's Code JavaScript." To learn more about Node.js, I decided to build the website for the screencast myself, rather than using something like WordPress.
This code was a pleasure to work with. I had written with tests, so it was easy to change and evolve. Starting around 2018, I decided to start evolving to support more than one site, with the goal of eventually migrating my blog off of Blosxom. I did this gradually, in my spare time, as kind of a fun side project. Mostly it involved cleaning reversing questionable design decisions involving globals, and cleaning up bad tests so I could do so.
By 2020, the codebase had evolved into a general-purpose content management engine. I migrated my content from Blosxom. In 2022, I migrated a PHP website a third party built for another business I was involved with. Now the system handles three websites, all on a single server: letscodejavascript.com, jamesshore.com, and agilefluency.org.
The result is so much better than using Blosxom, and I think it's better for my needs than anything I could buy. It's well tested, has a great development feedback loop, and any feature I want is a small code change away. For example, I replaced Google Analytics with simple email alerts that inform me when a piece of content gets a surge of attention. It was an hour or two of work.
I don't think there's any grand lessons to be learned from this, other than the one lesson everybody forgets when they're contemplating build vs. buy: it's not "the cost of building" vs. "the cost of buying". It's "the cost of building + maintaining" vs. "the cost of buying + the cost of keeping up with vendor updates + the opportunity cost of some feature changes being unsupported."
In my case, in 2018-2020, "build it yourself" was the right decision, because I had a robust codebase that I could evolve into a content management engine. In 2005, "buying" Blosxom was the right decision. I don't regret either choice, and I'm happy with where I've ended up.
I started blogging in earnest in 2005. At the time, I thought building my own blogging tool would be too much work, so I looked around for options that would allow me to store my content locally in source control. I settled on Blosxom, a Perl-based tool. Static site generators weren't really a thing in 2005, or I probably would have gone with that.
Blosxom served me well for 15 years, but it had problems. It ran on Apache, and every time I upgraded MacOS, I had to fiddle with Apache config to get it working again. It was customized with various plugins, and over the years I accumulated a lot of plugins and tweaks, to the point where I was afraid of making changes for fear of inadvertently breaking something. And it was very slow. I have a huge amount of content—I just checked, and it's currently at 6.9MB of text—and Blosxom couldn't handle the volume.
These problems meant that I eventually got to the point where I couldn't realistically make changes to the website any more. Blosxom had to be replaced.
Let's set that story aside for a moment. Back in 2012, I started a subscription-based screencast called "Let's Code JavaScript." To learn more about Node.js, I decided to build the website for the screencast myself, rather than using something like WordPress.
This code was a pleasure to work with. I had written with tests, so it was easy to change and evolve. Starting around 2018, I decided to start evolving to support more than one site, with the goal of eventually migrating my blog off of Blosxom. I did this gradually, in my spare time, as kind of a fun side project. Mostly it involved cleaning reversing questionable design decisions involving globals, and cleaning up bad tests so I could do so.
By 2020, the codebase had evolved into a general-purpose content management engine. I migrated my content from Blosxom. In 2022, I migrated a PHP website a third party built for another business I was involved with. Now the system handles three websites, all on a single server: letscodejavascript.com, jamesshore.com, and agilefluency.org.
The result is so much better than using Blosxom, and I think it's better for my needs than anything I could buy. It's well tested, has a great development feedback loop, and any feature I want is a small code change away. For example, I replaced Google Analytics with simple email alerts that inform me when a piece of content gets a surge of attention. It was an hour or two of work.
I don't think there's any grand lessons to be learned from this, other than the one lesson everybody forgets when they're contemplating build vs. buy: it's not "the cost of building" vs. "the cost of buying". It's "the cost of building + maintaining" vs. "the cost of buying + the cost of keeping up with vendor updates + the opportunity cost of some feature changes being unsupported."
In my case, in 2018-2020, "build it yourself" was the right decision, because I had a robust codebase that I could evolve into a content management engine. In 2005, "buying" Blosxom was the right decision. I don't regret either choice, and I'm happy with where I've ended up.