This is the core of the whole debate, in my experience:
"When it comes to build versus buy, the frequently repeated but rarely followed wisdom is good advice: if you're a technology company, vendors usually generate significant value if they're outside your company's core competency; within your core competency, they generally slow you down."
Every startup I've ever worked with has had engineers who advocated "build" for tooling that fell both outside the eng team's workflow and our company's core competencies.
I think part of it is that things like marketing automation or customer support software—things that are vital for most teams past a certain scale—don't seem technically "hard" enough to justify the price-tags, particularly to engineers who've been isolated from other parts of the business.
Without fail, every time I've been part of a team building an internal tool that we/another engineering team won't use, it goes poorly. I've spent way too long learning about the ins and outs of email deliverability so that I could fix a bug in a hacky email platform, when we could have just bought a platform that works.
Agreed - problem for me, as an engineer, is that I do like building those things that are outside my core competency so I can gain a wider variety of knowledge and experience.
Definitely not worth it from a business perspective, but has resulted in some interesting toy/hobby projects!
> I think part of it is that things like marketing automation or customer support software, don't seem technically "hard" enough to justify the price-tags
As someone who's built far too many of those because "Buying is just too expensive" ... good god do I never want to do that ever again. Ever. It's so fucking hard. You will shoot yourself in the foot. You will suffer. And 3 years later you still won't have something half as good as the purpose-built SaaS.
If you do that and enjoy it, just spin it off into its own product. Who knows, you might even get more customers with more expensive problems than the original startup.
This only makes sense if you have a significant equity stake in the company you're working for. For the vast majority of engineers, they really don't care about the long-term profitability/success of whatever company they're working for. They just want to get paid, and hopefully grow as a dev in the process.
They'll learn more by building something in-house than by bringing in a saas and just writing glue for a living. If you want your engineers to make the decisions a founder would make, give them a significant equity stake.
It depends. Significant stake helps of course and despite that, I'd prefer solving problems that need solving than spending a bunch of time on problems that don't :)
"When it comes to build versus buy, the frequently repeated but rarely followed wisdom is good advice: if you're a technology company, vendors usually generate significant value if they're outside your company's core competency; within your core competency, they generally slow you down."
Every startup I've ever worked with has had engineers who advocated "build" for tooling that fell both outside the eng team's workflow and our company's core competencies.
I think part of it is that things like marketing automation or customer support software—things that are vital for most teams past a certain scale—don't seem technically "hard" enough to justify the price-tags, particularly to engineers who've been isolated from other parts of the business.
Without fail, every time I've been part of a team building an internal tool that we/another engineering team won't use, it goes poorly. I've spent way too long learning about the ins and outs of email deliverability so that I could fix a bug in a hacky email platform, when we could have just bought a platform that works.