
Ask HN: Resources on how to build internal/enterprise tools? - internal_tools
There is a lot of attention given to consumer facing tools and how to build an MVP for that market segment. But what if your customer is internal (or a known enterprise)? Are there any good resources that discuss strategies on building these tools?<p>It seems like there is a lot of knowledge out there, as every company I have worked for has teams for internal tooling -- but very little public or communal knowledge.<p>Perhaps it&#x27;s because the problem isn&#x27;t as &quot;sexy&quot; as consumer tooling and products?
======
ismail
Hi, Have some experience in this area. As we often build apps that are used
internally for customers.

What @selmet said hits the nail on the head

"From my experience, requirements don't come from bottom but it should.
Initiator is almost always manager who might have some idea or vision but it's
not right originator."

Having said that, the same principals that apply for "consumer apps" would
apply to internal enterprise tools.

Here is some of what i do when consulting:

\- Start with "what is the problem you are trying to solve?, what are you
trying to achieve?"

\- Is the envisioned tool/app/software going to actually solve this problem?

\- How can we get more data to validate or disprove this?

\- What are the minimum set of features needed (MVP) to get it in front of
users?

\- If the sponsor/initiator is not the actual person the software is targeted
or is far removed from the actual problem. Speak to the actual users on the
ground, the people who are trying to solve this every day. Effectively do
customer dev with them (from startup world)

\- Depending on the organization, you may find some resistance if you focus on
user needs. This is usually driven by "bigger pay checks = better opinions"
type thinking. What you need to do here is get people to understand the
problem, and how the features being added are specifically towards solving
them and nothing else.

The knowledge gained, and paradigm shift you get having been in a startup,
even a failed one is tremendously useful. You will find when you get into more
traditional enterprise you are thinking different to most people there, you
see things in a different light. Always looking for the quickest path to
validate, and ensure you are heading in the right direction.

------
LarryMade2
I find building toward ease data entry and access - not what looks pretty

Make entry as easy as possible text entry for times & dates - with a tooltip
calendar, (unnecessary pop-up lists are a pain for anything when entering
bunches of records.) Consider using chekboxes and radio lists for selection
over popuplists sometimes they provide visual cues easier then reading or
expanding a popup.

Reduce complex multi-table entry forms to one screen, same with displaying
data... Make it so in reports where you might need to correct entry staff can
click right to record edit instead of having to back out, etc.

Try to make every bit of data collected usable, don't just have a "office
hours" field have a schedule entry so you can draw on the data - down the road
someone will say, I saw you collect X, can we use that to do Y? Be prepared to
say "no problem."

~~~
LarryMade2
Another big thing on internal/enterprise apps is access and administrative
tools. As a lot of people are working on your data some only have limited
program access, or access to only certain datasets... also others can check on
activity of how the data is entered/accessed/updated, might also be some sort
of job logging going on.

------
ahazred8ta
"strategies on building these tools"

The mechanics of actually building stuff, or the part where you want to get
paid for it? Could you expand on that a little?

------
selmat
From my experience, requirements don't come from bottom but it should.
Initiator is almost always manager who might have some idea or vision but it's
not right originator. And this is the main issue. He is trying to remove
outward manifestation not root cause. Employees are always struggling with
deeper issues than manager is trying to solve.

Practical example: I am working with huge amount of data about customer's
network infrastructure. Every item (device/contract/ticket) has own web page.
There is huge items with wrong or dummy data. If I need report, verify and
amend certain data i can't do it via bulk requests or automatically. Our
application doesn't have such interface, we don't have API, we don't have CLI.
I did talk to architect and he said me...no, we don't have it, and you are the
first one who asked for it. Nobody need it. So sorry but no.

Another example: internal tool, have some features but are wrongly
implemented. I reported that it doesn't work as expected. I received reply
that nobody use it, so there is no chance to get resource for fix and
improvement.

And another one...manager bring idea with time saving and required new
internal tool which will do automatically sign-in to all day-to-day tools. It
saved almost 5 minutes. But after password change it very often locked users
account. In total it wasted few hours of raising incident with internal IT.

And I have lot of similar experiences. So from my point of view here are key
features for corporate internal tools:

1) If tool or function doesn't work - hide it or remove it

2) If documentation is available - do it properly. Have some documents with
terminology explanation. Explain purpose and dependency between fields. Also
explain what is mandatory and why. This is whole story how can proper
documentation save your time and money. Everybody need to understand what they
use and why they have to fill field A, B, C and optionally D. You can save a
lot of time, money and issues, especially with newcomers. This documentation
can be studied at any time during future work. You can avoid misinterpretation
from older colleague etc.

3) If tools are developed always talk to end user not only with manager. Ask 5
times why should we solve this? Isn't the real issue somewhere else?

4) Internal tools always needs to be supported from management. Otherwise is
very small chance that your effort will be appreciated.

5) If you create tool have CLI version. GIU is some kind of protection against
stupidity but it also restrict improvement and speedup of whole process.

6) If you work with data, use standardized format like csv, xml or json. Same
format needs to be used for import and export. If other internal tools use csv
don't use xml or json and vice-versa.

7) Other internal tools have to be able work with same format. Export from
tool A have to be applicable (or with small amendment, no more than several
clicks/removal and copy-paste actions) into tool B. So your format what is
standardized for other tools.

8) Don't use insane level of nested features and choices. Something like
Audit-> Results -> Failed/Succeeded -> Details/Settings/Re-run -> (Details)
Result/Rule/Config/History -> (Result part) Output: " Filed X, Y, Z wasn't
find in config" ... and you are thinking wtf? Why? And you have to open
different window and verify it manually. I need to know what was found and why
it didn't match. Very often is due to wrong regexp pattern, but it take almost
30 minutes to verify all possible paths and find root cause.

9) Use universally applicable language/environment. From my experience you
create something which works at computer/server A but it will fail on
computer/server B.

And there are tons of other issues I dont remember. Some of them are technical
(software/system/hardware) some of them are social - people/management. I
would say social issues is much harder to overcome than technical. Social
issues are also more important, because if it fail to solve, entire
project/tool can be damaged. Technical issues can be solved almost every time.
If solution A doesn't work we can create B, but we always solve it.

