Running a business means making decisions, living with them, and occasionally realizing it’s time to revisit them. This week, that meant revisiting one of the oldest product questions: build or buy?
Buying saves you time until managing the thing you bought starts eating into the time you were trying to save. But if you don't own the implementation, you still own the outcome.
As a solopreneur, there's only so much of me to go around. My default answer, especially for non-core technology, is to buy. It's typically faster, cheaper, industry-vetted, and comes with support. You don't always get exactly what you want, but if you can get close, then it's usually a win.
It's useful to buy when I'm not deeply familiar with the technology involved. I've learned that I could do something internally, but it will take longer than I ever anticipated, robbing me of the time to ship my own products.
But there are often hidden costs involved. If you don't directly own the work yourself, then you're going to be managing the work instead. No product is ever perfect, so that means time invested in reporting bugs and filing feature requests. Then there are the long-term costs: licensing, support, and the internal validation needed to make sure the tool still works the way your product needs it to. And although you might be buying for speed, you're also buying a dependency.
While developing Outpost and Sherpa, I've needed a way for users to select a date. But my development framework isn't consistent in look and feel across operating systems. So I decided to use a control from a third-party that would provide a seamless experience for both Windows and macOS.
That worked great, until it didn't. I later learned that there was a substantial delay when typing in a value under macOS that felt slow and unreliable. So this week I spent time filing a bug only to discover that there wasn't anything that could be done to improve the situation.
The third-party control was cheaper until the missing behavior became product debt. Rather than live with the situation and ship Outpost with a basic interaction that felt wrong, I changed direction again and built my own date control. It wasn't hard and frankly a bit of fun, especially as I already had a preliminary version of what I needed in another project.
But I quickly knew where things were going and why I chose not to build initially. Within an hour or two I had something that worked great and did exactly what I needed. But then it took another hour or two of validation, tweaking for edge cases and buttoning things up so that it could easily be reused in future projects. This extra cleanup time turned a one-off fix into a reusable internal asset. It ended up being a worthwhile long-term investment, but it did cost half a day of work that I wasn't anticipating.
Unless a dependency starts getting in the way of the product experience, I still believe in buying first rather than building from scratch. But I've gotten better about knowing when a dependency has crossed the line from being a helpful shortcut to a drag on the product.
Running a business means making decisions, living with them, and occasionally realizing it’s time to revisit them. This week, that meant revisiting one of the oldest product questions: build or buy?
Buying saves you time until managing the thing you bought starts eating into the time you were trying to save. But if you don't own the implementation, you still own the outcome.
As a solopreneur, there's only so much of me to go around. My default answer, especially for non-core technology, is to buy. It's typically faster, cheaper, industry-vetted, and comes with support. You don't always get exactly what you want, but if you can get close, then it's usually a win.
It's useful to buy when I'm not deeply familiar with the technology involved. I've learned that I could do something internally, but it will take longer than I ever anticipated, robbing me of the time to ship my own products.
But there are often hidden costs involved. If you don't directly own the work yourself, then you're going to be managing the work instead. No product is ever perfect, so that means time invested in reporting bugs and filing feature requests. Then there are the long-term costs: licensing, support, and the internal validation needed to make sure the tool still works the way your product needs it to. And although you might be buying for speed, you're also buying a dependency.
While developing Outpost and Sherpa, I've needed a way for users to select a date. But my development framework isn't consistent in look and feel across operating systems. So I decided to use a control from a third-party that would provide a seamless experience for both Windows and macOS.
That worked great, until it didn't. I later learned that there was a substantial delay when typing in a value under macOS that felt slow and unreliable. So this week I spent time filing a bug only to discover that there wasn't anything that could be done to improve the situation.
The third-party control was cheaper until the missing behavior became product debt. Rather than live with the situation and ship Outpost with a basic interaction that felt wrong, I changed direction again and built my own date control. It wasn't hard and frankly a bit of fun, especially as I already had a preliminary version of what I needed in another project.
But I quickly knew where things were going and why I chose not to build initially. Within an hour or two I had something that worked great and did exactly what I needed. But then it took another hour or two of validation, tweaking for edge cases and buttoning things up so that it could easily be reused in future projects. This extra cleanup time turned a one-off fix into a reusable internal asset. It ended up being a worthwhile long-term investment, but it did cost half a day of work that I wasn't anticipating.
Unless a dependency starts getting in the way of the product experience, I still believe in buying first rather than building from scratch. But I've gotten better about knowing when a dependency has crossed the line from being a helpful shortcut to a drag on the product.
What about you? How do you decide to build in-house versus buy off the shelf?