
Ask HN: Is it a waste of time to code internal tools? - Sreyanth
I see a lot of companies (especially startups &amp; small businesses) with dedicated teams&#x2F;engineers to build internal tools for their support and other internal teams. It seems like it is really time-consuming &amp; engineering heavy depending on the use case.<p>I think I just developed a prototype that can build internal tools automatically (to a great extent), for any company, and has inherent support for dealing with certain entities such as users, cards, payments etc., As easy to set up as Stripe, and as easy to use as Zapier. All of this instantly, with minimal coding (only if you want to change the visual appearance of the tools generated &amp; add custom logic using JS &amp; Python). Also, there are efforts to integrate this product with other tools like Salesforce, ZenDesk, Kissmetrics etc.,<p>This product will reduce the time spent in developing internal tools, and the engineers in these teams could be used to build something even better.<p>So the question here is:
Is it a waste of time to code internal tools manually? What are the issues you frequently encounter in your companies w.r.t internal tools (development &amp; usage).<p>Also, is anyone interested to be an early adapter and use our product to generate internal tools for your companies&#x2F;products (for free)?
======
ohazi
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
Exactly. A program that solves this problem could probably also program the
external tools too.

~~~
Sreyanth
Can't agree more!

------
koiz
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
> 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
Docker was created as an internal tool at dotCloud.

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

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

------
ziikutv
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
> 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
That kind of sounds like an ORM no?

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

------
bamboozled
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!

------
zubat
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
Its more like a wizard, and seems very similar to
[https://developers.google.com/appmaker/](https://developers.google.com/appmaker/).

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

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

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

~~~
Sreyanth
I agree! :D

------
tdeck
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!

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

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

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

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

------
bArray
@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
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
Also, just realized. It is adopter, and not adapter. My bad. Was too sleepy to
realize what I typed.

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

[https://developers.google.com/appmaker/](https://developers.google.com/appmaker/)

~~~
Sreyanth
Ah, shit. Yes. :(

Should I be giving up?

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

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

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

------
schwede
What type of internal tooling are you generating?

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

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

So, a new programming language?

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

~~~
Sreyanth
@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

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

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

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

~~~
Sreyanth
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?

