Internal tools often make bad startup ideas
philosophicalhacker.substack.com
philosophicalhacker.substack.com
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Does anyone know how the failure rate of startups based on internal tools, stacks up against the failure rate of startups at large?
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.
GP and myself are in agreement that the widely understood history is as I laid it out (given they said it was a myth). Happy to link to some info on the history of AWS, but its not the point of this thread I think
It's also on the Wikipedia page, with references to the appropriate articles/talks. https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
This is not some secret or hidden piece of knowledge requiring extensive research..
EC2 was sold to customers long before it was functional and secure enough for Amazon itself to use.
> EC2 was developed first and foremost for Amazon's internal infrastructure. It started out as an idea in the head of Chris Pinkham, who worked as an engineer in charge of Amazon's global infrastructure in the early 2000s.
> "It struck us in the infrastructure engineering organisation that we really needed to decentralise the infrastructure by providing services to development teams," Pinkham says. "That was a big motivating factor."
Someone here is lying. I really couldn't care less who's right or wrong, I'm just using publicly available information.
This is probably the case for 99% of all arguments I witnessed in my career.
They are many AWS products that are a derivative or variation of internal tools, but they are effectively almost always rewrites with significant changes. The dogfooding comes much later.
Source: I once worked there while they were migrating workloads to these AWS systems.
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.
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.
They are well funded, but do they actually make money? Seems like the odd one out in your list.
"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.”
An idea can he great. The execution exceptional. But if it's too soon (and likely too difficult to communicate) then it can still fail.
Success is rare. So rare mircles happen more often.
I don’t know how well you would have to execute „Facebook for dog owners” to actually beat Facebook.
There is also whole bunch of seemingly not bad ideas like making Jira alternative - I bet one can make money in that niche but you will have to invest so much that most likely you won’t earn as much as you would expect because you won’t get F500 companies to use it as much as they use Jira.
Even if you build team „something will stick eventually” doesn’t sound like a good idea unless you have infinite money.
Which in turn moves us to the money where real fun begins - some ideas just don’t have earning potential and you can easily tell that dropping 500k on something that will generate 100k a year will earn you back the money in 5 years. Going for idea that will generate 50k is going to be bad idea.
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"?
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)
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.
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.
Thus, harvesting these ideas and recasting them as standalone businesses whose costs to clients are potentially deductible makes sense.
It usually starts when a team is quite small, and someone builds some DevOps pipelines that nicely automate deployment to dev and test environments. When it comes to production deployment, it seems natural to simply duplicate the same pipelines -- however, production is generally quite different from other environments:
1. There is an approval process, which does not exist for other environments. Even if it is possible to have it fully automated (I have yet to see it in practice), it requires rigorous tests and verification of the code; and if it is not automated, the process generally involves plenty of back and forth communication between testers, product owners, developers etc.
2. Ideally, deploying to production should not involve rebuilding the project anew. Once you deploy it to a testing environment, and it passes all the tests, deploying the exact same artifact (docker image, ZIP file, Python wheel, binary executable or whatever) to production is the only way to ensure that you're deploying what has been tested and approved.
I have searched for a third-party tool to manage this process, but haven't found anything satisfactory yet (suggestions welcome!) -- one of the reasons is probably the fact that the processes differ so wildly between companies and teams.
I don't know where you work, but automated continuous deployment has been an industry standard for fifteen years.
I feel the question isn't where a tool/idea originates.. it should be, does this tool/idea provide effective, appropriately-priced, accessible, problem-oriented features that target market-derived problems?
Also, there are problems seeking solutions, and solutions seeking problems. It's important to know which case you're looking at. It can be more difficult to be a solution seeking a problem.
I have been both an engineer and a product manager. I built internal tools, and tools for sale externally. When I learned more about formal product management, it made so much more sense where to start.
This is an oversimplification but, if you're doing fundamental R&D or internal tools, and not trying to yet build a publicly facing business, then focus on the purpose you are trying to unlock. If you're trying to build a publicly facing, sustainable business, focus on identifying a market problem, and building problem-oriented features to address them, making those solutions available and visible to those who need them, and acquiring/serving customers.
The beauty of some of this is that, these days it can be possible in some cases to focus on identifying something that is a market problem, make a minimal version of the solution visible with low investment, find out if this is something that makes sense to continue to build, and then iterate rapidly.
A lot of the above is regurgitated "best practices in product management", to be fair, but overall I've found it really helpful guidance.
Of the many engineering roles I've held over the years, building internal applications was one of the most enjoyable, mainly because I could directly observe whether our software was working well for its customers. It strikes me as an advantage to serve an internal customer first, if you get the opportunity to know them really really well and then use that knowledge effectively.
The problem is internal tools are less then 1% of what an actual multi-tenant product would be. So the skills to build an internal tool, don't always map to the rest of the 99%.
The first issue I see is that you don't know if you hate it until you're neck deep in the mud. So your selling point is probably further than where the decision will be made.
I'd like to see the data comparing internal -> external success rate vs just starting out B2B.
Also, there is an advantage to starting with an internal system because you are relentlessly devouring your own dog food.
As the author of a internal tool that I just converted to a failing SaaS, I know!
So hard in fact, that engineers are flooded with free tools.
The examples people quote here are more properly services than tools.
not that I haven't seen some really interesting tools.
When purify first came out, I tried a demo license and promptly fixed many bugs. But management didn't want to buy some onerous per-seat license for it.
I also remember checking out electric cloud, which replaced make, but made all the make pain go away. It would hook into the file system and find hidden dependencies and fix things. Same thing, why would management pay to make engineer's life easier.
Maybe this is like mechanics. They buy their own tools.
Companies that buy tools for their employees mostly buy the bare minimum. Nowadays that's a "practical" dell desktop and a "practical" dell monitor with maybe an MS keyboard and mouse. and/or a practical laptop.
All business software are tools.
Sometimes internal tools exist because the incentives are there for a company to build rather than buy.
Sometimes internal tools exist because the right tool just isn't on the market. Yet.
Same with Basecamp from 37signals.
DEVELOPER TOOLS INSPIRED BY EXISTING INTERNAL TOOLS
If you build a cool dashboard, that might not sell as well as some sort of ugly integration with some horrible legacy system.
This makes the point a bit weaker imho
golinks.io
It was the internal company aspiring to be a paas provider and failing to do so.
> In fall 2003, the World Online developers (Adrian Holovaty and Simon Willison) ditched PHP and began using Python to develop its websites. As they built intensive, richly interactive sites such as Lawrence.com, they began to extract a generic web development framework that let them build web applications more and more quickly. They tweaked this framework constantly, adding improvements over two years.
I think docker the company not succeeding as a unicorn has more to do with trying to position it as a unicorn than a viable business built upon something in that original offering
I think the place where you're most likely to find success in selling tools is being a team that works for a cloud provider. Developers can just start using it, and someone else gets the bill. If you're a developer and have to start paying the bill somehow, that can be challenging in many organizations, and that's why "I'll just write it myself" is so popular.
That was almost ten year later since Docker was released as open source.
That's why I think developer tools are a very risky business. Your salesperson emails a developer in the wrong tone, and suddenly they just up and cloned your company over a 4 day weekend out of pure spite. (That was not Podman's story, rather, a large company decided to do that. Similar to the registry-screw-turning; gcr.io, quay.io, AWS's thing, etc.)
We create our internal tools because buying puts us in a terrible position. For example SAP would do what our internal tools do. However SAP would cost more than our yearly revenue to implement. It would require expensive experts to configure for use and it would lock us in.
Instead we have built a system that is working very well in a little over a year. With one developer.
Sometimes what's on the market is not a good fit.