9 ms·

Internal tools often make bad startup ideas

88 points by kmdupree 3y ago

znpy 3y ago
Weird that no one mentioned docker as a counter-example. It was the internal company aspiring to be a paas provider and failing to do so.
- entropie 3y ago
  Or rails.
  - fcsp 3y ago
    Please elaborate
    - entropie 3y ago
      Rails was the internal tool/backend of basecamp and got later its own project with great success.
      - fcsp 3y ago
        But rails wasn't the pivot of Basecamp into devtools, it was just a by-product, and hence rails never needed to take VC money to become a unicorn
  - selcuka 3y ago
    Django, too [1]: > 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/ https://docs.djangoproject.com/en/dev/faq/general/
  - insane_dreamer 3y ago
    but 37signals didn't try to turn Rails into a business
    - entropie 3y ago
      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.
      - fcsp 3y ago
        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.
- fcsp 3y ago
  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
  - jrockway 3y ago
    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.
    - znpy 3y ago
      > 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.
      - jrockway 3y ago
        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.)
greyface- 3y ago
The obvious counterexample here would be Slack, which started out as the internal comms tool for Tiny Speck, makers of the former MMO Glitch (RIP).
- BadHumans 3y ago
  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.
elevaet 3y ago
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.
- karamanolev 3y ago
  > 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.
  - BadHumans 3y ago
    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.
    - calvinmorrison 3y ago
      yet here we are in 2024 emailing ourselves files
      - deleted 3y ago
        [deleted]
    - kmdupree 3y ago
      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
- 3y ago
hallicopter 3y ago
Another counter example – Jira by Atlassian started as a project management tool for their agency. Same with Basecamp from 37signals.
- fcsp 3y ago
  Those examples are both well over 20 years old though, so not sure how well this translates to companies that start today
lijok 3y ago
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?
- kmdupree 3y ago
  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).
  - lijok 3y ago
    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
  - tobr 3y ago
    Could you give an example where “<category description> often make bad startup ideas” would be false?
    - yowlingcat 3y ago
      "Products where as a market representative buying persona I've tried to purchase a good product and found nothing good"
  - NomDePlum 3y ago
    Was Twitter not an internal tool? Not sure hit rate is anywhere close to the statistic to measure startups by either. Successful ones are called Unicorns for a reason.
politician 3y ago
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.
- kmdupree 3y ago
  OP here. very interesting point!
deleted 3y ago
[deleted]
dvt 3y ago
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. Genuinely confused.
- altdataseller 3y ago
  To be fair his bio says wannabe philosoph professor, so I don’t think he actually is one?
- jolt42 3y ago
  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.
- adamsilkey 3y ago
  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.)
mberning 3y ago
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.
- drewcoo 3y ago
  I'd argue that most internal tools are lesser copies of something else external. Sometimes because of lack of awareness sometimes just NIH syndrome.
- wruza 3y ago
  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.
wruza 3y ago
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.
marsissippi 3y ago
Good short post. Good short quote: "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).
- kmdupree 3y ago
  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"
- preommr 3y ago
  > "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?
  - cyanydeez 3y ago
    learning a Kafka wrapper is useless.
jagged-chisel 3y ago
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.
- caesil 3y ago
  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.
dosinga 3y ago
Two posts below is YC's request for startups. #5 is: DEVELOPER TOOLS INSPIRED BY EXISTING INTERNAL TOOLS
- marcosdumay 3y ago
  I imagine that is the reason why people posted this one here.
- romanhn 3y ago
  This post is literally a follow-up to the YC request.
lxe 3y ago
So basically "Internal tools that are fun to build make bad startup ideas" If you build a cool dashboard, that might not sell as well as some sort of ugly integration with some horrible legacy system.
elromulous 3y ago
Go links are one example, created at Google. golinks.io
kromem 3y ago
I think this notion can be more generalized: "most ideas are bad startup ideas." 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.
- carloslfu 3y ago
  Banger! This is it!
- brettv2 3y ago
  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.
- zztop44 3y ago
  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.”
  - Etheryte 3y ago
    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.
    - chiefalchemist 3y ago
      And of course there's timing, as well as marketing. 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.
m463 3y ago
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.
- mgummelt 3y ago
  > tools in general are a hard sell, maybe an extremely hard sell. All business software are tools.
deleted 3y ago
[deleted]
a-dub 3y ago
the world wide web was an internal tool.
xupybd 3y ago
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. Sometimes what's on the market is not a good fit.
- fakedang 3y ago
  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.
ang_cire 3y ago
> 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.
- rcxdude 3y ago
  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.
  - convolvatron 3y ago
    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?
    - jamesfinlayson 3y ago
      Or the inevitable migration to another tool because the current off-the-shelf solution is now too expensive/has been relicensed/whatever.
sixdimensional 3y ago
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.
patorick002 3y ago
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.
tqi 3y ago
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"?
- OkayPhysicist 3y ago
  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.
- jamesfinlayson 3y ago
  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.
- insane_dreamer 3y ago
  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)
Donaldzibe 3y ago
[dead]
wtracy 3y ago
I would say this post makes more sense to me as a call for self-awareness among potential founders than as an argument for avoiding this route entirely. 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.
y1426i 3y ago
I haven't seen any idea for which there isn't a successful startup, company or exit. 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%.
aussieguy1234 3y ago
Well, most startups fail. But then a few become unicorns.
BerislavLopac 3y ago
One set of internal tools that I have repeatedly seen companies struggle with are the release management tools. 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.
- mgummelt 3y ago
  > I have yet to see it in practice I don't know where you work, but automated continuous deployment has been an industry standard for fifteen years.
some1else 3y ago
Citation needed.
XCSme 3y ago
Funny how I just Tweeted[0] about planning to convert an internal tool into a product. [0]: https://twitter.com/XCSme/status/1758116735016669434 https://twitter.com/XCSme/status/1758116735016669434
renegade-otter 3y ago
Wasn't Docker developed as an internal tool? 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!
jurschreuder 3y ago
Buying Kafka is mentioned as an example but Kafka was in fact first an internal tool at Linkedin. This makes the point a bit weaker imho

88 points by kmdupree 3y ago

znpy 3y ago

Weird that no one mentioned docker as a counter-example. It was the internal company aspiring to be a paas provider and failing to do so.

entropie 3y ago
Or rails.
- fcsp 3y ago
  Please elaborate
  - entropie 3y ago
    Rails was the internal tool/backend of basecamp and got later its own project with great success.
    - fcsp 3y ago
      But rails wasn't the pivot of Basecamp into devtools, it was just a by-product, and hence rails never needed to take VC money to become a unicorn
- selcuka 3y ago
  Django, too [1]: > 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/ https://docs.djangoproject.com/en/dev/faq/general/
- insane_dreamer 3y ago
  but 37signals didn't try to turn Rails into a business
  - entropie 3y ago
    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.
    - fcsp 3y ago
      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.
fcsp 3y ago
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
- jrockway 3y ago
  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.
  - znpy 3y ago
    > 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.
    - jrockway 3y ago
      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.)

greyface- 3y ago

The obvious counterexample here would be Slack, which started out as the internal comms tool for Tiny Speck, makers of the former MMO Glitch (RIP).

BadHumans 3y ago
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.

elevaet 3y ago

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.

karamanolev 3y ago
> 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.
- BadHumans 3y ago
  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.
  - calvinmorrison 3y ago
    yet here we are in 2024 emailing ourselves files
    - deleted 3y ago
      [deleted]
  - kmdupree 3y ago
    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
3y ago

hallicopter 3y ago

Another counter example – Jira by Atlassian started as a project management tool for their agency. Same with Basecamp from 37signals.

fcsp 3y ago
Those examples are both well over 20 years old though, so not sure how well this translates to companies that start today

lijok 3y ago

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?

kmdupree 3y ago
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).
- lijok 3y ago
  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
- tobr 3y ago
  Could you give an example where “<category description> often make bad startup ideas” would be false?
  - yowlingcat 3y ago
    "Products where as a market representative buying persona I've tried to purchase a good product and found nothing good"
- NomDePlum 3y ago
  Was Twitter not an internal tool? Not sure hit rate is anywhere close to the statistic to measure startups by either. Successful ones are called Unicorns for a reason.

politician 3y ago

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.

kmdupree 3y ago
OP here. very interesting point!

deleted 3y ago

[deleted]

dvt 3y ago

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. Genuinely confused.

altdataseller 3y ago
To be fair his bio says wannabe philosoph professor, so I don’t think he actually is one?
jolt42 3y ago
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.
adamsilkey 3y ago
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.)

mberning 3y ago

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.

drewcoo 3y ago
I'd argue that most internal tools are lesser copies of something else external. Sometimes because of lack of awareness sometimes just NIH syndrome.
wruza 3y ago
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.

wruza 3y ago

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.

marsissippi 3y ago

Good short post. Good short quote: "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).

kmdupree 3y ago
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"
preommr 3y ago
> "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?
- cyanydeez 3y ago
  learning a Kafka wrapper is useless.

jagged-chisel 3y ago

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.

caesil 3y ago
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.

dosinga 3y ago

Two posts below is YC's request for startups. #5 is: DEVELOPER TOOLS INSPIRED BY EXISTING INTERNAL TOOLS

marcosdumay 3y ago
I imagine that is the reason why people posted this one here.
romanhn 3y ago
This post is literally a follow-up to the YC request.

lxe 3y ago

So basically "Internal tools that are fun to build make bad startup ideas" If you build a cool dashboard, that might not sell as well as some sort of ugly integration with some horrible legacy system.

elromulous 3y ago

Go links are one example, created at Google. golinks.io

kromem 3y ago

I think this notion can be more generalized: "most ideas are bad startup ideas." 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.

carloslfu 3y ago
Banger! This is it!
brettv2 3y ago
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.
zztop44 3y ago
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.”
- Etheryte 3y ago
  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.
  - chiefalchemist 3y ago
    And of course there's timing, as well as marketing. 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.

m463 3y ago

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.

mgummelt 3y ago
> tools in general are a hard sell, maybe an extremely hard sell. All business software are tools.

deleted 3y ago

[deleted]

a-dub 3y ago

the world wide web was an internal tool.

xupybd 3y ago

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. Sometimes what's on the market is not a good fit.

fakedang 3y ago
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.

ang_cire 3y ago

> 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.

rcxdude 3y ago
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.
- convolvatron 3y ago
  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?
  - jamesfinlayson 3y ago
    Or the inevitable migration to another tool because the current off-the-shelf solution is now too expensive/has been relicensed/whatever.

sixdimensional 3y ago

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.

patorick002 3y ago

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.

tqi 3y ago

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"?

OkayPhysicist 3y ago
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.
jamesfinlayson 3y ago
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.
insane_dreamer 3y ago
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)

Donaldzibe 3y ago

[dead]

wtracy 3y ago

I would say this post makes more sense to me as a call for self-awareness among potential founders than as an argument for avoiding this route entirely. 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.

y1426i 3y ago

I haven't seen any idea for which there isn't a successful startup, company or exit. 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%.

aussieguy1234 3y ago

Well, most startups fail. But then a few become unicorns.

BerislavLopac 3y ago

One set of internal tools that I have repeatedly seen companies struggle with are the release management tools. 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.

mgummelt 3y ago
> I have yet to see it in practice I don't know where you work, but automated continuous deployment has been an industry standard for fifteen years.

some1else 3y ago

Citation needed.

XCSme 3y ago

Funny how I just Tweeted[0] about planning to convert an internal tool into a product. [0]: https://twitter.com/XCSme/status/1758116735016669434 https://twitter.com/XCSme/status/1758116735016669434

renegade-otter 3y ago

Wasn't Docker developed as an internal tool? 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!

jurschreuder 3y ago

Buying Kafka is mentioned as an example but Kafka was in fact first an internal tool at Linkedin. This makes the point a bit weaker imho