3 ms·

It's not a waste of time to develop in-house tools, sometimes in-house tools become the future of a company. For small businesses there's definitely a market f

by koiz 9y ago

It's not a waste of time to develop in-house tools, sometimes in-house tools become the future of a company. For small businesses there's definitely a market for automation platforms but there's a lot of problems in actually selling these products. You either focus on a key area where they already have a solution they don't question or you go too broad and confuse the people you're selling to. Like let's be honest, your tool can't build everything. I think the question you gotta ask is why is your tool builder better than the frameworks and resources that devs already have available to them.

robotmlg 9y ago
> sometimes in-house tools become the future of a company. e.g. Slack started as an internal messaging tool at a game development company
- city41 9y ago
  Docker was created as an internal tool at dotCloud.
manyxcxi 9y ago
I spent some time building an internal tool for rapid testing during our implementations at the time. Maybe two weeks to initial concept, 3 months later it was driving a surge in our team profitability. A decade later the idea has spawned at least three separate companies, a couple of patents (not necessarily in love with that), and an evolution of that idea is how I feed my family. Internal tools can be just another tool that makes people's lives easier. They can be an albatross when they become someone's little fiefdom, or they can become Slack. You never know where they can go, but the bigger questions before I go building my own: Is there anything that already gets me close? Usually Can we change how we're doing things to better fit something that exists?
13of40 9y ago
I end up coding in-house versions of things like language and document parsers that are available open source, just for licensing reasons. For example, a lot of open source licences only kick in when you distribute the derived work, and that's fine, but it's not clear whether the on-premise instance of our service that the Chinese government runs is a "distribution" or if that's still in-house.

by koiz 9y ago

robotmlg 9y ago

> sometimes in-house tools become the future of a company. e.g. Slack started as an internal messaging tool at a game development company

city41 9y ago
Docker was created as an internal tool at dotCloud.

manyxcxi 9y ago

I spent some time building an internal tool for rapid testing during our implementations at the time. Maybe two weeks to initial concept, 3 months later it was driving a surge in our team profitability. A decade later the idea has spawned at least three separate companies, a couple of patents (not necessarily in love with that), and an evolution of that idea is how I feed my family. Internal tools can be just another tool that makes people's lives easier. They can be an albatross when they become someone's little fiefdom, or they can become Slack. You never know where they can go, but the bigger questions before I go building my own: Is there anything that already gets me close? Usually Can we change how we're doing things to better fit something that exists?

13of40 9y ago

I end up coding in-house versions of things like language and document parsers that are available open source, just for licensing reasons. For example, a lot of open source licences only kick in when you distribute the derived work, and that's fine, but it's not clear whether the on-premise instance of our service that the Chinese government runs is a "distribution" or if that's still in-house.