6 ms·

Ask HN: Is it a waste of time to code internal tools?

• 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.
• tensor 9y ago
  I suspect there are already a lot of tools like the one you've built. Two examples are knack.com and ragic.com. Now, maybe your's is better, but it's good to be aware of the competition. Sadly, companies often end up going with something like salesforce, which I hear also has the ability to be extended like these more general tools (though they try to sell consulting services to do so). The reason companies go with something like salesforce is that 80% of what they need is already built and done in a pretty targeted way. For the rest they can have an in-house dev or a consultant extend it and integrate it with whatever other tools the company is already using.
  • tomxor 9y ago
    I think we have different definitions of "tool"
  • Sreyanth 9y ago
    I just realized I built something similar to https://developers.google.com/appmaker/ https://developers.google.com/appmaker/ Irony, I wrote it for AppEngine, didn't host it though.
• dvdhsu 9y ago
  I'd be interested in taking a look; email is in profile.
  • Sreyanth 9y ago
    Sure. At this point its just a really weird prototype. I was thinking of getting a few early adopters, build a product to serve their needs and then extend it. Should I still contact you over email?
• dkarapetyan 9y ago
  You will be competing with the likes of salesforce and an army of salesforce "integration experts". I guess I'm saying your target market might not be who you think it is and you're probably better off talking to the salesforce integration experts and figuring out how to solve their pain points.
• deleted 9y ago
  [deleted]
• ziikutv 9y ago
  Selling a magical pill without providing pharmacology is no different than selling snakeoil. Share your solution please, unless that part in your question is just a digression; (addendum) does not seem to be the case from the last paragraph. To answer your question, it depends. Anecdotally, we created custom solution for analytics for our Robot, and then moved it in as a solution. You can think of it like 'internal-pivot'. Additionally, in-house tools, if designed correctly, are usually small pieces of software that do just what a company needs. Tailored solutions, if effectively created, are sometimes better than something out of the box. It also lets the developers stay stimulated when there is not 'actual work' to be done and adds potential for features to be implemented for their product; if not providing with something they can pivot and sell separately.
  • Sreyanth 9y ago
    > Selling a magical pill without providing pharmacology is no different than selling snakeoil. Agreed. I was just not sure if it was a good idea to share my solution as the answers would be mostly anlayzing the solution. I wanted to know more about the problem - and see if such a problem really exists. But briefly, here is how it works. 1. You give the schema of your DB to the tool. 2. The tool analyzes and build backend flows. 3. The user can now select which fields indicate the username, card or payment amount etc., and the flows will be adjusted for the same. 4. User can add access control to tables and fields. 5. Preview and publish, and the tool is ready to be used. Since a single tool like this cannot build tools for specific usecase, there is an option to define own actions and layouts.
    • ziikutv 9y ago
      That kind of sounds like an ORM no?
• aubee 9y ago
  IMHO, crafting something useful, useable and making sense isn't waste of time, especially when you are paid to do that and your product is considered as your KPI. You are paid to do that, at least it means that worth your compensation, right?
  • Sreyanth 9y ago
    Yes, but when it can be automated and the engineering resources could be used for building something even more useful, I think that's a clear decision for the business?
• nolite 9y ago
  This doesn't make any sense unless you specify what you mean by "internal tools"
• CodeWriter23 9y ago
  Standard cost benefit analysis: does the time spent coding and maintenaning the tool offset by time savings or value improvements? Your pitch is whether you can come in and present a build or buy choice...I think the internal problem space is pretty vast, but if you think you've got something to offer and you can present useful functionality in ten lines of code, you might have a chance. You'll need to get some people raving about how much time and headache saved, I don't think any amount of conventional marketing will convince your target audience.
• tyingq 9y ago
  Sounds somewhat like the "App Maker" tool Google has in limited beta. https://developers.google.com/appmaker/ https://developers.google.com/appmaker/
  • Sreyanth 9y ago
    Ah, shit. Yes. :( Should I be giving up?
    • tyingq 9y ago
      There is one big problem with Google's implementation. Only users in the Gsuite domain where it was created can access it. So, for example, if you wanted to create an applicant tracking system, the job applicants wouldn't be able to sign into the app to uploade their resumes or see status. If you think they won't ever fix that, there's an opening there. It's an odd limitation to me. I suppose they are trying to sell GSuite licenses.
      • Sreyanth 9y ago
        I think they will. Or probably they want to use this to get more GSuite users? I am not sure. Most of the startups that I know of which take tools seriously are already using GSuite. Will need to see how my tool will add any value to them.
        • tyingq 9y ago
          Well, offering the ability to run on premise would be a difference. Most of the tools in this space don't do that. Ragic, Knack, Zoho Creator, Quickbase, etc. Or maybe tie it to AWS with a pre built AMI? There are at least some companies where a point-and-click AWS instance would have value.
          • Sreyanth 9y ago
            My tool enables the users to deploy the tools generated wherever they want. It will anyways be deployable to AWS, Azure, GCloud, Digital Ocean and Heroku with a single click - using their own credentials. Do you think pre-built AMIs might be a good idea? I am not sure about it though.
• ohazi 9y ago
  What exactly does "internal tools" mean to you? Maybe my definition is overly broad, but I've worked on teams that developed and maintained internal tools such as compilers, renderers, visualization tools, signal analysis tools, payload decoders, packaging and provisioning tools, etc. I think it's highly unlikely that we're talking about the same thing here.
  • bArray 9y ago
    Exactly. A program that solves this problem could probably also program the external tools too.
    • Sreyanth 9y ago
      Can't agree more!
  • Sreyanth 9y ago
    I am sorry I didn't highlight this in the question. I didn't mean the in-house tools we build to make our dev's work easier, but to make it easier for the non-dev members of the company. I was referring to all those web UIs we build in companies for our internal tools to use to service our customers, help our sales guys achieve their targets etc., In other words, we could just think of them as an UI with the production DB's slave in the backend which allows the internal teams to consume/edit data. Think of user management tools, log analysis tools, sales trackers, fraud trackers etc.,
• binarymax 9y ago
  "General-purpose tools are not enough, however. Both specialized needs and personal preferences dictate the need for specialized tools as well; so in discussing programming teams I have populated one toolmaker per team." - "The Mythical Man Month" p 128, "Sharp Tools".
• codewritinfool 9y ago
  Depends on the job. For example, I write super low-level embedded code, and it is advantageous for us to control all allocation of code space and memory space. The reason is so that patches can be very small. To help with this, we have very specific tools that help us with visual allocation maps, custom diff tools and patch generators, etc. This may never become mainstream - the resources are just too small for widespread adoption. Just my $0.02
• skraelingjar 9y ago
  Internal tools are not a waste of time. I have built them for previous employers and for my company. Those tools solved critical issues while saving time and money. It made more sense to build than to use current solutions. There are plenty of cases where it doesn't make sense. I am not surprised companies build tools even when it isn't logical. I would like to try your product, if I find it useful I might be willing to pay.
  • Sreyanth 9y ago
    Sure. At this point its just a really weird prototype. I was thinking of getting a few early adopters, build a product to serve their needs and then extend it. Should I contact you on your email?
• zubat 9y ago
  What else is "scripting" but that act of making a very small automation of a business function? Is a customized spreadsheet a tool? There's always going to be demand for tools of many kinds, so whatever you're offering has to differentiate better than "internal tool". The abstract you give is kind of like a software framework, possibly with some form of high level scripting, configurator, or wizard to guide the user. At the end of the day always evaluate your solution against a short bash or Python script. Did your solution gain anything? If not, why?
  • Sreyanth 9y ago
    Its more like a wizard, and seems very similar to https://developers.google.com/appmaker/ https://developers.google.com/appmaker/.
• tdeck 9y ago
  This reminds me a bit of The Last One, a program for generating business software on demand. It was released in 1981 and supposed to be the last program you'd ever need to buy. You can guess how that (and every subsequent such product) turned out in the end. That's not to say don't try, but be aware that this is harder than it looks!
  • Sreyanth 9y ago
    I agree. I was just trying to avoid a few very trivial things that each of the budding startups spend time in writing. But yes, its definitely harder. Perhaps it seems like I am looking at it vaguely and broadly, but I will narrow it down to a specific type of tool or to a specific type of business.
  • GFischer 9y ago
    Some of those are still around (here in Uruguay we have a tool called Genexus that's been around for like 20 years and generates code in almost any language, the OP might want to look into that https://www.genexus.com/global/home?en https://www.genexus.com/global/home?en ). The problem is, they're still programming languages, but very opinionated They look like magic if you go the way the tool allows you to go, but when you go off the rails you end up wasting more time than if you had coded it in a standard language.
    • Sreyanth 9y ago
      GeneXus seems interesting, though my tool isn't exactly like GeneXus, it does overlap a bit in the sense of not requiring to code and easy to develop UI etc.
• joshmn 9y ago
  I'm interested in taking a look. josh[at]josh[dot]mn
  • Sreyanth 9y ago
    Sure. At this point its just a really weird prototype. I was thinking of getting a few early adopters, build a product to serve their needs and then extend it. Should I still contact you over email?
• bArray 9y ago
  @Sreyanth: Internal tools of a given type? Perhaps. Sounds payment orientated. You need to put this in the title. I would also like to point out that you're asking people whether they want to be an early "adapter" of a product you haven't described or referenced. "I think I just developed" doesn't install any confidence into startup wanting to adopt your mystery software, either you have or you haven't. Opinion: What you're describing sounds like a large API. I think you may struggle to get adoption if you're looking for money from this software.
  • Sreyanth 9y ago
    Thanks for pointing out @bArray. I intentionally avoided describing the product as I wanted to know more about the problem space, so I can come up with the right solution using this prototype. But I just realised that Google is working on something similar: https://developers.google.com/appmaker/ https://developers.google.com/appmaker/
    • Sreyanth 9y ago
      Also, just realized. It is adopter, and not adapter. My bad. Was too sleepy to realize what I typed.
• sotojuan 9y ago
  No, because they're a lot funner to code than customer-facing tools.
  • Sreyanth 9y ago
    I agree! :D
• peterkelly 9y ago
  > I think I just developed a prototype that can build internal tools automatically So, a new programming language?
  • joshjje 9y ago
    No, the singularity.
  • Sreyanth 9y ago
    No, a web based UI which basically does the work of providing an interface to the DB (think of phpMyAdmin), but also adds meaning to the data based on the entities and teams that need the data. For example, the tool processes the DB schema, builds a UI. Learns which field is username, and then shows in the front end the way user management softwares work. For the sales guy, its just all the information from Salesforce, different forms, the value of their converted leads. For the finance team, its the payments, fraud disputes etc., All this data is in the DB. And engineering efforts go in to build these tools for the non-engineers and keep re-iterating. I am trying to solve that problem of re-inventing the wheel. Any functions specific to the business can always be added using JS or Python (just like Zapier).
    • GFischer 9y ago
      It sounds really useful, but are you sure non-programmers will be able to do stuff with it? There's a continuum of automation software, non-programmers often find themselves comfortable writing stuff in Excel, and some become kind-of self-taught programmers using something like VBA, Access, or whatever is used today, but they are still not programmers and don't understand how your "magic" tool works. If your tool has the ease of use for non-programmers as Excel you might have something big. If not, you still might have something useful :) but understand your audience :) .
      • tyingq 9y ago
        It is an already crowded space. Quickbase, Fusioo, Ragic, Knack, Zoho Creator, Google App Maker, etc. I've used most of them, and they end up being frustrating. Quickbase was the most flexible of the lot, but it's expensive. I haven't tried Google's. It sounds like it has a problem many of these tools share though. Per user pricing, with no notion of "external users". Think something like job applicant tracking. You couldn't offer an external user portal to upload a resume without paying a license for every applicant.
• dguaraglia 9y ago
  Like everyone else is saying: it depends. If there's a tool that will save your employees a few minutes a day and it'll take one of your engineers a few days to write, it might be worth it. There's even a handy XKCD about it: https://xkcd.com/1205/ https://xkcd.com/1205/
  • Sreyanth 9y ago
    This is exactly what the tool does! It takes a few minutes to set it up or modify. Engineers would've otherwise spends days writing, another week testing and deploying.
• schwede 9y ago
  What type of internal tooling are you generating?
  • Sreyanth 9y ago
    Not the in-house tooling for devs, but for non-devs in the company to support their daily tasks.
• joshjje 9y ago
  Companies build internal tools, usually when it makes financial sense to do so. Us developers do the same thing on a smaller scale when we automate tasks we find ourselves doing repeatedly. Teams/companies that find themselves similarly doing something repeatedly, and costing lots of time will do the same. Obviously to be successful it needs to be something that makes sense and where the time saved by it will outweigh the time spent on it. And excuse me, I dont know what your tool is or does, but there is no way that it could replace even a fraction of this development (though that doesnt mean it wouldnt be useful or profitable). Otherwise it would be intelligent enough to replace developers entirely.
• bamboozled 9y ago
  In my opinion you probably know the answer to this question, that's why you're asking, that is you know it's probably a waste of time. The best advice I could give is ensure you're doing it for the right reasons, that everyone around you will truly profit and make sure you've honestly evaluated existing tools. I often see people failing to correctly evaluate an existing technology/tool and then rush off to build their own inferior product. Yes it can be fun to just code, and there are cases where it's truly a good / beneficial thing to do, but they're not common from my experience. Good luck!