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

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.

Exactly. A program that solves this problem could probably also program the external tools too.

Can't agree more!

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

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.

> sometimes in-house tools become the future of a company.

e.g. Slack started as an internal messaging tool at a game development company

Docker was created as an internal tool at dotCloud.

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?

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.

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

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

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.

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

That kind of sounds like an ORM no?

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.

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!

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?

Its more like a wizard, and seems very similar to https://developers.google.com/appmaker/.

This doesn't make any sense unless you specify what you mean by "internal tools"

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.

No, because they're a lot funner to code than customer-facing tools.

I agree! :D

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!

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.

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

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.

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.

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.

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.

I think we have different definitions of "tool"

I just realized I built something similar to https://developers.google.com/appmaker/

Irony, I wrote it for AppEngine, didn't host it though.

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

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/

Also, just realized. It is adopter, and not adapter. My bad. Was too sleepy to realize what I typed.

Sounds somewhat like the "App Maker" tool Google has in limited beta.

https://developers.google.com/appmaker/

Ah, shit. Yes. :(

Should I be giving up?

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.

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.

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.

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.

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.

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?

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?

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?

What type of internal tooling are you generating?

Not the in-house tooling for devs, but for non-devs in the company to support their daily tasks.

> I think I just developed a prototype that can build internal tools automatically

So, a new programming language?

No, the singularity.

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

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

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.

@tyingq. That's a brilliant point, and am glad that you pointed it out.

We were thinking of per-user pricing only for the employees. The tools generated will have an "Allow external user signups" option that would allow external people to signup, and then the external users' traffic would be charged by the hosting company (or by us if the user chooses us to host their tools for them). I think this is a normal way of doing it, and I believe these tools will soon switch into this mode, if not, I am glad :D

Thanks for pointing that out!

I am guessing it will be as easy as Excel for the non-programmers to use the tools generated using my tool. But, only the users can say.

In fact, we were debating on providing an Excel like interface (which will be auto-created if the table has too many columns, and can be manually created if required) that just boosts productivity when performing data manipulation jobs.

We saw that most non-programmers, when confused, just look for an export option first, so that the data can be analyzed in Excel. Then they modify it in Excel, upload it on to the systems again - so yes, have a tough competition here with Excel, but we are trying to get that easy to use factor into the online interface to make sure the non-programmers won't have to use multiple tools to get a single job done.

But I really hope we come with a product that generates tools that are super-easy to use. Might take time, but that's where we want to go.

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/

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.

I'd be interested in taking a look; email is in profile.

I'm interested in taking a look. josh[at]josh[dot]mn

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?