Discord was also an internal tool from a game company. Most game companies have internal tools that could be a startup product on their own with a bit of tweaking.
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.
iirc, dropbox was actually very technically challenging, which is why they tested the idea with a mock landing page first before building it (source: Lean Startup) and steve jobs famously spoke with drew about what he'd built early on
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.
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?
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
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
Do you have sources that confirm that this was the case? Otherwise, none of the counter proof that you demanded would be needed, saving everybody some research time
Woah, let me be clear, I am not demanding anything, nor are we looking for “counter proofs”, this is a simple discussion on some interesting AWS history and potentially myths surrounding it
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
> 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.
Actually, they can be both true: it could have been developed for Amazon's internal use, but sold to the public before the target internal customer was sold on adopting it.
that's not how I understood the history: AWS was a result of a strategy of making amazon's infrastructure into its own business unit (with the basic idea that any future internal projects should also be suitable to sell to someone else, because they would be). It took quite some time for them to migrate from 'internal tool' to 'suitable to sell to someone else', they didn't just do it because they happened to have those tools.
It's the other way around. The public offerings were built and only much later were they used internally, at least with any widespread adoption.
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.
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.
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.
It’s my understanding that changes in tax treatment for software development and the exclusion of internal tools from the R&D tax credit will result in teams being denied authority to develop internal tools (along with other things like 20% time for tinkering).
Thus, harvesting these ideas and recasting them as standalone businesses whose costs to clients are potentially deductible makes sense.
> 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.
Well they kinda did. The early rails was rarely well documented. You had to buy books (developed by the rails team) to get everything together. At least I felt this way when I dived into rails pre 1.0.
I'm not sure it's fair to criticise a company that puts it's secret sauce open source under a very liberal license for not spending more resources on writing free docs as their main priority. The growing community very quickly took up on that one and the docs got very good fast.
I think it's pretty clear that docker as the software extracted from the initial paas is by any means wildly successful to this day.
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 they're having trouble selling the actual tool, though. Docker turning the screws on Docker Desktop users has resulted in a lot of people saying "we'd rather just switch to Podman".
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.
> I think they're having trouble selling the actual tool, though. Docker turning the screws on Docker Desktop users has resulted in a lot of people saying "we'd rather just switch to Podman".
That was almost ten year later since Docker was released as open source.
That's why I'm saying it's a questionable company. Would Docker have been as popular if it was closed source $100/month/seat? Would Docker have been as popular if they had registry pull rate limiting on day 1? No. They just lived off of VC for half a decade, then when that went away, they had to say "oh shit we better turn the screws", but by then, everyone had cloned their thing.
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.)
Well, I think after taking the VC money that was lying on the table they focused on the wrong thing, trying to become a unicorn, where many companies have emerged building devtools around docker containers that have at least made solid exits, and this is something that docker could have provided itself instead of chasing whatever
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.)
I agree with this. People will argue by counterexample, but those are the exception rather than the rule. Most internal software is so specific to the company or industry that it came from that the broad applicability is nearly nil. That implies a very high unit price, which is not going to fly for a piece of niche software.
Also, an internal toolkit may look great at the "internal" stage, but become a mess once you try to package it into a product. I've seen and made lots of these for ERPs and stock ops, but every time I thought about making it at least an internal product, it failed. Two reasons: 1) making a product is 10..50x harder than making a solution; 2) extracting your knowledge into an easily consumable form is almost as hard as training a user to replace yourself. Even if you finish it, it will cost much more than just a hire. And the world doesn't have issues with hires atm.
A corollary of this is that internal tools that require developers to do unpleasant work or learn a non-career-advancing skill are more promising candidates for startups. Integrating with existing systems, especially legacy ones, is a nice example of work developers hate doing
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.
"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?
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.
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.
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.
It would be pointless in a vacuum. There are actually bad ideas.
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.
tools in general are a hard sell, maybe an extremely hard sell.
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.
I'm in this position right now and I have to call BS.
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.
That's the point isn't it? What might be an innovative internal tool, isn't likely to be a good startup idea? In your case, your tool would have to compete with SAP, making it a very uphill battle to dethrone SAP.
> 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.
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?
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.
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.
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.
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.
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.
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.
> 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.
> 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.
> 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.
Disclaimer - I'm not a ridiculously successful expert, but below is what I've gleaned from my experience:
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.
Yep. If you build a worse version of commercially available product in a market that has viable incumbents, just because you felt like building something, that probably wouldn't be a good foundation for a startup. It probably wouldn't be a good idea for an internal tool either; even if it wins you some short-term recognition. I've also seen people get promoted for shutting stuff like that down.
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.
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"?
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.
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.
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)
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.
117 comments
[ 2.8 ms ] story [ 223 ms ] threadMaybe 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.
Same with Basecamp from 37signals.
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.
Thus, harvesting these ideas and recasting them as standalone businesses whose costs to clients are potentially deductible makes sense.
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.
[1] https://docs.djangoproject.com/en/dev/faq/general/
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.)
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.)
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.
"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?
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.
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.
golinks.io
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.
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.
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.
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.
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.
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.