Subscribe
Sign in
Build vs. Buy Calculator — Should you build an internal tool? Or just buy it?
23
Replies
Best
Mubashar Iqbal
While I agree with the premise here, its often not that black and white (is anything?!?).
Does the buy option do everything you want. What are the integration costs of using that off the self solution? Another important factor is that you may eventually outgrow the buy option, and what will it cost to move to something more custom.
If you *can* make the buy option work, you probably should, as it saves you time and money in the short term, the two things most startups are struggling to find.
Report
Share
@mubashariqbal The problem is most startups think that "everything you want" is actually necessary to growing their business. There are very few business problems that startups face in the first 0-5 years that haven't already been solved with existing software.
Obviously there are edge cases, but 99% of startups are not edge cases...they just think they are.
@shpigford That's probably very true, but I think that's a problem in all aspects of doing a startup, not just the build vs buy debate for internal tools.
@shpigford Couldn't have said it better myself --> "Obviously there are edge cases, but 99% of startups are not edge cases...they just think they are."
@ckeck exactly. also I think it's important to understand that this is a nice "start" to the conversation of build vs. buy; not replacing any of the human elements or obviously complex, underlying decision making. it's a great tool to quickly understand "what's in store" and @shpigford is always great and providing tools and context for which way to look when you come to a fork in the road.
Any startup that creates B2B software inevitably runs in to customers who say "we'll just build this ourselves instead of pay you for it!" which is almost universally an awful idea.
A while back, I wrote an article on the topic (because we hear this a lot at Baremetrics): https://baremetrics.com/blog/bui...
After that article, a tweetstorm on the topic, and the help of our buddy John from Ghost, we decided to create a little calculator to show how building internally just almost never makes sense for business software.
This quote from Henry Ford sums it up well: "If you need a machine & don’t buy it, then you will ultimately find that you have paid for it & don’t have it."
@shpigford I fell into this trap so many times early on in my career. Some of this depends on if a tool exists to do what you want. Or if people market that tool effectively so you can find it.
But yeah, writing software should always be a last resort because software is a living thing and if you aren't working on it, it is decaying on you.
@shpigford great idea! One thing that people often forget is that maintenance != new features, thus you're stuck with the same product while the service hopefully has been improving over time. Also, it is always hard to throw away something that you have invested a lot of capital into, so when that custom built solution doesn't meet your needs a lot of companies stick with them even though there are better solutions out there.
@shpigford Love that quote! Cannot count the hours I have spend convincing businesses that re-inventing the wheel is a dumb idea.
@shpigford This is awesome, why didn't it exist before!? Wrote a blog post about the exact same topic a month ago too: https://medium.com/@Amitch5903/b...
@shpigford 100% agree with the general message
but to paraphrase what @mubashariqbal said - it doesnt take several additional costs into account for buying: decision, integration, opportunity, etc
eg good example are marketing automation suites - might end up to be perfect what you need but the integration might take quite some time (not the "here you put script a" but the actual "ok this now actually makes sense to work with"), when done you might realize you dont need half of the stuff it offers and the other half handles two core aspects differently than you expected thus renders it half useful
or other tools where you halfway in the integration realize your usecase is more a addon patch to it and isnt really as neatly supported as imagined
usually what makes external software expensive is not the "buy" but the integrate
baremetrics is a perfect example of buy & done tools that uses mainly industry language - these kind of tools are usually a nobrainer
btw:
imo this is where most saas tools define their future potential in growth:
if the customer needs to learn you thinking, language and universe to be able to use your tool you create a huge initial cost and will have a hard time (read enterprise sales) growing.
same is true for technical integrations
@andreasklinger @shpigford @mubashariqbal echoing these comments, I've been struggling with transitioning from a manual spreadsheet for tracking SaaS metrics, to a software solution. It is a time sink to do it manually, but then I know with certainty it's correct (and boy would it cause problems to be wrong about them).
Every SaaS metrics app I've tried has been a nightmare time suck to try to import my data, and for the one I did get data in it's all so wrong, it doesn't feel like it's worth the headache to try to reconcile it. I'm not sure I could ever trust it's 100% accurate.
As great as the ROI calculator is, it doesn't help you calculate time to configure it, nor your confidence in the tool. For anything essential core to your business, it can often make sense to build even if it does cost more, especially as you grow. However, this should be a *very* short list.
I use tons of SaaS tools and get a lot of benefit, but there's a handful of cases where essential parts of the business just make sense to do yourself. You have to trust the data, and if it has to absolutely work, then who better than your own team to own it, especially as you get bigger?
Great! I can see a potential in making this into a more advanced tool/product, e.g. starting with simple can I pass variables via URL, like https://baremetrics.com/calculat...... then I can send our prospects a link to this with pre-filled values and some context - companies might be willing to use it to have their own page, e.g. calculator/inlinemanual - we are being asked that question so many times - upvoted :)
@shpigford brilliant. It was a matter of time until somebody builds one and I'm glad it's the good people behind Baremetrics
Ha! Good stuff. I think it's a matter of thinking about what is core to your product and what's not. If this "thing" is really one of the top 1-3 reasons why your customers choose your product, then you should own the experience. If it's not, find an outside solution - even if it doesn't cover every "edge case" (love @shpigford's comment - "Obviously there are edge cases, but 99% of startups are not edge cases...they just think they are.")
I have an excellent example of where building was the far better option than buying. At my company, I needed a solution to text my editors whenever there is a new email to edit. At first, I found a service called PagerDuty, which I hated. The UI was complex, they were expensive ($30/month per editor), the text alerts couldn't be customized, and after researching the company some more, I found that their values were not in alignment with my own (I might write a Medium article on that last bit some day). So, I paid a developer $500 to build a solution using Twilio to send the text alerts. Now I'm not paying a monthly fee, the text alerts look exactly the way I want them to, I have granular control over who gets alerts when, and all the texts come from one single number (as opposed to hundreds of short codes), which keeps my phone's text feed a lot cleaner and organized.
I'm a big proponent of buy over build (at least for the first step). I hate to build and then realize the feature is a fail. This is a great way to determine whether or not to SWITCH to build once the bought feature has been validated, rather then continue "renting". Great work @shpigford!
Great idea! Why aren't you taking into consideration the initial build cost?
very interesting concept, curious about the reliability - will try to find you guys next time we have a dilemna like this