> companies may stop naively believing engineers who say they can build what a vendor is offering in 2 weeks
I love to build tools out rather than buy tools, but it's not for the resume line item, and it's not for the love of development (I'm not actually a software dev, I'm infosec). I prefer to implement tools internally, when feasible, because it makes them more likely to be understood and utilized.
80% of the functionality in 90% of the tools we buy is un-utilized or under-utilized. We are constantly having vendors or tool owners offering training credits for us to learn the unnecessary bells and whistles of the tool they spent too much money on.
In contrast, the tools we build have no unnecessary features. No key functions that are *future roadmap items* for a vendor. No black-box processes that we can only shrug when asked what it's doing or how, because it's 'proprietary' secret sauce for the vendor.
Now, do most of those tools merit their own business? Not at all, and we don't try to sell them, but many of them would make great open-source projects.
Just because something would not generate money, does not mean it's not a good and worthwhile project.
I do feel that often the cost of integration in the 'buy' solution is often overlooked: there are many fantastically expensive products you can buy which will do almost anything you can imagine, if you spend the time and effort to figure out the platform and 'configure it how you want ' (where configuring requires a software engineer because it's varying degrees of disguised programming) . It's very easy to spend more time and money doing this than an in-house solution would.
I've been saying this for more than TWO DECADES: the entire "build vs. buy" is a false premise. There is no such thing as "buy".
There is "build", and then there is "buy and build". Without the proper integrations and customisations, any tool you have bought is just one more (possibly worse than) useless line item in your budget.
I was leading such a team at previous employer focused on building integrating various tools to turn this tool soup into something palatable.
The main challenge is the increasing complexity of software and processes that necessitate such tools as the engineering team grows. Usually teams building internal tools are seen as cost centers and don't get the same funding as product teams which eventually leads to teams buying more than build to save on future maintenance.
don't forget maintenance. that's often a point made against internal tooling, but when was the last forced upgrade you had to do because an internal tool just doesn't support the old environment anymore?
> because it makes them more likely to be understood and utilized
So my take is that this is mostly wrong, unless your organization is really good at maintenance, documentation and training.
Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood. Relying on internally developed tools put you at risk, because what frequently happens is that only a few people know how to maintain and develop for your internal thing. Maybe that's their job, but mostly it's not, it's something that happens on the side.
We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution, saving us from having 10 small home grown and distinct solutions. Sure, there would be features we didn't need, but we'd get security updates and be able to throw out tons of boiler plate code. Some people just love coding and will see any problem as an excuse to write a new tool, only to abandon it once some new problem catches their eye and then the rest of us are stuck with their abomination.
Another tools of ours was developed to avoid providing training on a open source tool. So now we have a wrapper the ensures that "the process" is always done safely. No new features are added, so people spend unnecessary time fighting a tool, trying to make it do things it doesn't want to do. All because nobody wanted to create the required training material. Actual documentation on the wrapper is so severely limited that new hires have zero chance of actually using it to do anything remotely complex.
There can be really good reasons for developing an internal tool, but those better be damn good reasons and the organization must be able to bear the cost, most aren't.
> We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution
I would also consider self-hosted FOSS tools under the "build" category rather than "buy", so I would have no objection to using those versus re-building an available FOSS tool yourself. It's OSS, so you have the code, so you know what it's doing and how. It's self-hosted, so you aren't reliant on a vendor. It's (hopefully) free, so no vendor is trying to sell you on a module you don't need.
> Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood.
I think the key question here is, "who is using the internal tool?" To my mind, this is about teams building the tools THEY need, so it is nigh impossible to develop the tool but not understand it. You're not handing it off to another team, you built it because YOU need it. There can absolutely be abysmal documentation, but not having documentation and not looking at extant and extensive documentation is functionally equal, and the latter is by far the default state of tool use.
Your comment sounds as though in your mind some team is being mandated to build a tool for another team, against that other team's wishes. Is that internal to the company? Sure. Is it self-rolled? Not if the people using it didn't make it them*selves*. In that case it's really just a vendor tool, but the vendor is much less invested in the tool.
> Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood.
Not been my experience at all. The business people absolutely know that tool inside and out, just because your development teams have high turnover doesn't mean that tool hasn't been taught to everyone who uses the software.
In fact, my experience is that when a bug is introduced unknowingly the business side can describe you very concretely what it used to do and what they want it to do.
Being able to contextualize your security tooling to the code level is such an underrated capability of an effective security program/team.
It also allows you to leverage open-source tooling much more effectively.
The biggest problem is your setting a bar for capabilities that allot of infosec people don't have, so you need to consider the ability to manage a custom security code base into the future, which can cause issues if it's not considered properly for the environment your doing it in.
Yes, of course. I know some people want to build something and then hand it off, but personally I love to actually use and improve the tools I make.
Even with my personal projects, I find myself going back to my old projects and adding stuff to them, much more often than I find myself starting brand new ones.
Maintenance is easy if you don't suck at retention. As much as engineers like to build they also really enjoy gardening.
The only compelling argument I have heard for buy over build is "well, our engineers keep leaving". Yeah, because you are terrible at managing them - so no shit they leave.
A competently managed technical team has some natural attrition but the rates of turnover I see in a lot of companies that push this ethos is far beyond normal or healthy.
All software becomes "legacy" in short order if you are constantly hemorrhaging tribal knowledge and skills.
in addition, vendors tend to build things for a large variety of environments, and not just your specific use case. so new features would require more thought and consideration than an internal implementation for your company's specific environment.
that said, I think if what a vendor provides checks every box for your use case, buy is probably better than build.
There are many counterexamples to this point. Temporal, Slack, Nango, Trello, GitHub, Jira, Intercom, AWS, basically every Terminal SaaS out there, Mailchimp, Asana, Zapier, Shopify, Hubspot, etc
Does anyone know how the failure rate of startups based on internal tools, stacks up against the failure rate of startups at large?
Trello was built, from its inception, to make a marketing splash at TechCrunch Disrupt 2011. It didn’t start as an internal tool. Sure, we dogfooded (…dogfed?) it, but that was Fog Creek’s culture for every product we launched.
FogBugz DID start as an internal tool, which was more profitable than Trello (pre-Atlassian), but it’s going to turn 25 this year. Don’t make business decisions based on software that could register as an antique, if it were a car.
AWS was never really an internal tool. The idea that Amazon had all this extra capacity and decided to open it up is a myth. AWS was always a deliberate strategy. Now, you could argue that it arose out of the expertise they acquired in building API-first infrastructure, but I think that’s different than a lot of these examples.
SQS, S3 and EC2 were all internal systems that they decided to start offering publicly at some point. That’s the widely understood history. I’d love to read anything contrary to that, sounds very interesting
It was more of a symbiotic evolution with both goals mind.
On the business side, Amazon externalized every little piece of its retail business into a product, from the website itself (target.com), 3P sellers, FBA, etc.
OP here with a friendly reminder that we should also look at the denominator when evaluating how useful the "internal tools make good startups" heuristic is.
Also note that I'm not claiming they are never good ideas, so pointing out instances where they've panned out isn't very interesting. It'd be more interesting if you could show that the hit rate among these types of startups is better than I'm suggesting (for that we need to consider the denominator).
Apologies, I was actually going to finish my comment with “does anyone know how the fail rate of such startups stacks against the fail rate of startups at large?”
But I got carried away with trying to recall all the companies that started out as internal tools, that I forgot
"You can also bet that a full stack js dev would rather buy your Kafka wrapper than learn Scala, which will do nothing for her career prospects."
The implicit point is that we often abstract to the level of the company, but we can (sometimes more profitably) abstract just to the level of the purchasing authority (and those are often different and have different incentives).
OP here. Yes! Thank you for seeing this! I make this point explicitly in a previous post called "Conflicting employee vs. business incentives slow B2B SaaS growth rates"
> "You can also bet that a full stack js dev would rather buy your Kafka wrapper than learn Scala, which will do nothing for her career prospects."
My reading comprehension is bad then because that's a very confusing sentence.
- There are lots of full stack devs that would rather learn scala than a kafka wrapper. In fact, I would say it's more likely because a full-stack dev is inclined to be more flexible and learn different tools.
- Not really sure that kafka and scala are one-to-one comparisons
- I am also not sure which one "which will do nothing for her career prospects" refers to. Is learning a wrapper for kafka useless, or is learning scala useless in that quote?
For a philosophy professor, I really don't get the thesis of this post. Is the point that engineers like to build stuff and most stuff they build won't be a successful startup? This seems extremely trivial and doesn't solely apply to internal tools (in fact, it applies to everything one builds). Is the argument that the signal is worse when it comes to internal tools rather than non-internal ones? Could be true (I dunno'), but there's no supporting evidence.
Yeah, also confused. I will say that when I look at off-the-shelf stuff often I'll find something that is %80 of what is needed, and that other %20 is more difficult to retrofit than something from built internally that can grow with the company.
I think the point is that engineers are capable of rebuilding internal tools, so internal tools as a product to sell to other companies may not be a great startup idea.
It'd be different if you were building internal tools for a group that couldn't replicate your work, like accountants or HR.
At least, that's what I got from it. (And I'm not saying I agree with the thesis.)
There’s a difference between bad startup ideas and bad startups. Execution is critical; a 90% failure rate doesn’t tell you anything about the quality of ideas.
Internal tools sound like they should be good startup ideas (see the YC call for startups on today’s front page). Arguing they’re not is making a specific point and different to “most startups will fail.”
Arguing over whether an idea is good or not is in general pretty pointless. Anyone can come up with the idea of flying cars, it's the execution that counts. If you manage to build a team with great execution, you will figure out something that sticks eventually.
Right, but the important difference between an internal tool and {any other start up idea} is that the internal tool, in theory, has "traction" - i.e. it is being used by people. By definition, you can't pose the same perceived value on something that _isn't_ an internal tool.
Reflecting on this, I kind of feel like the opposite has actually been true for the last 10+ years?
Early in my career, I saw many examples of homegrown AB test frameworks, event tracking frameworks, alerting tools, monitoring tools, etc. Now it seems like everyone just buys LaunchDarkly, Segment, DataDog, etc. Other than admin panels, I have a hard time thinking of any truly "internal" tools at my last few companies (FAANG was the exception, but they are big enough that I think it genuinely makes sense for them to build their own tools for things like applicant tracking, meeting booking, etc).
Maybe I'm just forgetting something - do other ppl have examples "internal tools"?
There are a few at companies that I've worked at.
- Two previous companies have had hand-rolled timesheet tools (I'm sure there are plenty of alternatives now but both were probably built in the mid 2000s when there were't many alternatives)
- A previous company had a integration environment booking tool - not sure why a custom solution was needed as any calendar tool should work but maybe there were some specific requirements (I was never a user of the tool)
- A previous company had a tool for release management that pull in a bunch of items from Jira and marry them up with items in version control to generate a set of release notes in a specific format - no idea if there are any alternatives for this one but I think it had a pretty specific set of requirements
None of the above would have been worth trying to monetise in my opinion.
There are lots of examples in the use cases section of any low-code vendor, but in short, most internal tools are not in the horizontal categories you listed. They're in vertical, industry-specific categories at SES (Software-Enabled Services) companies.
A quick commerce startup, for instance, is unlikely to find an inventory tracking app off-the-shelf that fits their workflow, since existing ERPs are not going to fit their workflow.
My company's got a handful of internal tools, but they're universally not useful to anybody else. We made a license creation tool that our manufacturing/sales teams use to make licenses for the hardware we sell, we have a stack of powershell scripts that create a bunch of required documentation from our bug tracker, and I made some custom tooling that made building our (nightmarish proprietary-language software) project easier to build.
build tools, often because they're so specific to the particular sw product
timesheet and similar types of tracking (often using Excel), again very specific to the particular org (it's more hassle to try to adapt some external tool)
Author says “often” and the comments here are all “no! See $COMPANY!”
Folks, there’s nuance here. They didn’t say “…always make bad startup ideas.”
There could be much more interesting meat here: how many startups are based on “internal tools”? How many of those succeed (for some definition of success)?
The problem with even answering that question is that I think the numbers parallel how-many-startups-launched vs how-many-startups-succeed. And if they track pretty closely, then the headline thesis isn’t novel.
In any case, shouting “nuh uh! Slack!” doesn’t really contribute to the conversation.
Yeah, almost any category you can name "often" makes a bad startup. YC-funded companies "often" fail. Building a venture-backed startup is the wrong career path if you're not willing to risk an unusually extreme chance of failure; everyone knows that going in.
As a counterexample, Slack started as in internal tool (from what I've heard), and turned out to be a very successful startup. And it wasn't the kind of thing engineers don't want to build, nor an integration of a legacy system.
Maybe all of the low hanging startup fruit of that variety has been plucked.
> Maybe all of the low hanging startup fruit of that variety has been plucked.
I felt that I agreed, but then I would have equally agreed right before Slack got so popular, so ... maybe not? We often don't see the long hanging fruit until it gets plucked.
Or rather, it's not as low hanging - just that the difficulty is not technical, it's that building something nice that works well together is just not easy, regardless of the vertical.
I'm of the opinion that engineers just don't understand how much ease of use is worth. The infamous Dropbox comment for example. Countless number of successful companies make tools that are not technically amazing but they just work and are designed well.
Not quite. Slack's roots are in a video game called Glitch. The game never made it out of the gate, but its messaging system found new life as Slack. Fun fact - this was Stewart Butterfield's second attempt at making a game. The first one ended up pivoting to Flickr.
Readit News
I love to build tools out rather than buy tools, but it's not for the resume line item, and it's not for the love of development (I'm not actually a software dev, I'm infosec). I prefer to implement tools internally, when feasible, because it makes them more likely to be understood and utilized.
80% of the functionality in 90% of the tools we buy is un-utilized or under-utilized. We are constantly having vendors or tool owners offering training credits for us to learn the unnecessary bells and whistles of the tool they spent too much money on.
In contrast, the tools we build have no unnecessary features. No key functions that are *future roadmap items* for a vendor. No black-box processes that we can only shrug when asked what it's doing or how, because it's 'proprietary' secret sauce for the vendor.
Now, do most of those tools merit their own business? Not at all, and we don't try to sell them, but many of them would make great open-source projects.
Just because something would not generate money, does not mean it's not a good and worthwhile project.
There is "build", and then there is "buy and build". Without the proper integrations and customisations, any tool you have bought is just one more (possibly worse than) useless line item in your budget.
The main challenge is the increasing complexity of software and processes that necessitate such tools as the engineering team grows. Usually teams building internal tools are seen as cost centers and don't get the same funding as product teams which eventually leads to teams buying more than build to save on future maintenance.
So my take is that this is mostly wrong, unless your organization is really good at maintenance, documentation and training.
Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood. Relying on internally developed tools put you at risk, because what frequently happens is that only a few people know how to maintain and develop for your internal thing. Maybe that's their job, but mostly it's not, it's something that happens on the side.
We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution, saving us from having 10 small home grown and distinct solutions. Sure, there would be features we didn't need, but we'd get security updates and be able to throw out tons of boiler plate code. Some people just love coding and will see any problem as an excuse to write a new tool, only to abandon it once some new problem catches their eye and then the rest of us are stuck with their abomination.
Another tools of ours was developed to avoid providing training on a open source tool. So now we have a wrapper the ensures that "the process" is always done safely. No new features are added, so people spend unnecessary time fighting a tool, trying to make it do things it doesn't want to do. All because nobody wanted to create the required training material. Actual documentation on the wrapper is so severely limited that new hires have zero chance of actually using it to do anything remotely complex.
There can be really good reasons for developing an internal tool, but those better be damn good reasons and the organization must be able to bear the cost, most aren't.
I would also consider self-hosted FOSS tools under the "build" category rather than "buy", so I would have no objection to using those versus re-building an available FOSS tool yourself. It's OSS, so you have the code, so you know what it's doing and how. It's self-hosted, so you aren't reliant on a vendor. It's (hopefully) free, so no vendor is trying to sell you on a module you don't need.
> Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood.
I think the key question here is, "who is using the internal tool?" To my mind, this is about teams building the tools THEY need, so it is nigh impossible to develop the tool but not understand it. You're not handing it off to another team, you built it because YOU need it. There can absolutely be abysmal documentation, but not having documentation and not looking at extant and extensive documentation is functionally equal, and the latter is by far the default state of tool use.
Your comment sounds as though in your mind some team is being mandated to build a tool for another team, against that other team's wishes. Is that internal to the company? Sure. Is it self-rolled? Not if the people using it didn't make it them*selves*. In that case it's really just a vendor tool, but the vendor is much less invested in the tool.
Not been my experience at all. The business people absolutely know that tool inside and out, just because your development teams have high turnover doesn't mean that tool hasn't been taught to everyone who uses the software.
In fact, my experience is that when a bug is introduced unknowingly the business side can describe you very concretely what it used to do and what they want it to do.
It also allows you to leverage open-source tooling much more effectively.
The biggest problem is your setting a bar for capabilities that allot of infosec people don't have, so you need to consider the ability to manage a custom security code base into the future, which can cause issues if it's not considered properly for the environment your doing it in.
Even with my personal projects, I find myself going back to my old projects and adding stuff to them, much more often than I find myself starting brand new ones.
The only compelling argument I have heard for buy over build is "well, our engineers keep leaving". Yeah, because you are terrible at managing them - so no shit they leave.
A competently managed technical team has some natural attrition but the rates of turnover I see in a lot of companies that push this ethos is far beyond normal or healthy.
All software becomes "legacy" in short order if you are constantly hemorrhaging tribal knowledge and skills.
And they want you to pay for the unused parts. It's frequent that products seem brutally expensive as a result.
that said, I think if what a vendor provides checks every box for your use case, buy is probably better than build.
Does anyone know how the failure rate of startups based on internal tools, stacks up against the failure rate of startups at large?
FogBugz DID start as an internal tool, which was more profitable than Trello (pre-Atlassian), but it’s going to turn 25 this year. Don’t make business decisions based on software that could register as an antique, if it were a car.
On the business side, Amazon externalized every little piece of its retail business into a product, from the website itself (target.com), 3P sellers, FBA, etc.
Deleted Comment
They are well funded, but do they actually make money? Seems like the odd one out in your list.
Also note that I'm not claiming they are never good ideas, so pointing out instances where they've panned out isn't very interesting. It'd be more interesting if you could show that the hit rate among these types of startups is better than I'm suggesting (for that we need to consider the denominator).
But I got carried away with trying to recall all the companies that started out as internal tools, that I forgot
Not sure hit rate is anywhere close to the statistic to measure startups by either. Successful ones are called Unicorns for a reason.
"You can also bet that a full stack js dev would rather buy your Kafka wrapper than learn Scala, which will do nothing for her career prospects."
The implicit point is that we often abstract to the level of the company, but we can (sometimes more profitably) abstract just to the level of the purchasing authority (and those are often different and have different incentives).
My reading comprehension is bad then because that's a very confusing sentence.
- There are lots of full stack devs that would rather learn scala than a kafka wrapper. In fact, I would say it's more likely because a full-stack dev is inclined to be more flexible and learn different tools.
- Not really sure that kafka and scala are one-to-one comparisons
- I am also not sure which one "which will do nothing for her career prospects" refers to. Is learning a wrapper for kafka useless, or is learning scala useless in that quote?
Genuinely confused.
It'd be different if you were building internal tools for a group that couldn't replicate your work, like accountants or HR.
At least, that's what I got from it. (And I'm not saying I agree with the thesis.)
An industry with a 90% 10yr failure rate isn't one where the majority of its members embody wisdom and foresight.
So there's counterexamples to internal tools being good products. But most are bad, just as most external tools are also bad startups.
Internal tools sound like they should be good startup ideas (see the YC call for startups on today’s front page). Arguing they’re not is making a specific point and different to “most startups will fail.”
Early in my career, I saw many examples of homegrown AB test frameworks, event tracking frameworks, alerting tools, monitoring tools, etc. Now it seems like everyone just buys LaunchDarkly, Segment, DataDog, etc. Other than admin panels, I have a hard time thinking of any truly "internal" tools at my last few companies (FAANG was the exception, but they are big enough that I think it genuinely makes sense for them to build their own tools for things like applicant tracking, meeting booking, etc).
Maybe I'm just forgetting something - do other ppl have examples "internal tools"?
A quick commerce startup, for instance, is unlikely to find an inventory tracking app off-the-shelf that fits their workflow, since existing ERPs are not going to fit their workflow.
timesheet and similar types of tracking (often using Excel), again very specific to the particular org (it's more hassle to try to adapt some external tool)
Folks, there’s nuance here. They didn’t say “…always make bad startup ideas.”
There could be much more interesting meat here: how many startups are based on “internal tools”? How many of those succeed (for some definition of success)?
The problem with even answering that question is that I think the numbers parallel how-many-startups-launched vs how-many-startups-succeed. And if they track pretty closely, then the headline thesis isn’t novel.
In any case, shouting “nuh uh! Slack!” doesn’t really contribute to the conversation.
Maybe all of the low hanging startup fruit of that variety has been plucked.
I felt that I agreed, but then I would have equally agreed right before Slack got so popular, so ... maybe not? We often don't see the long hanging fruit until it gets plucked.
Or rather, it's not as low hanging - just that the difficulty is not technical, it's that building something nice that works well together is just not easy, regardless of the vertical.