How do you develop internal tools for your organization?

Question

We are considering creating few internal tools to speed up the work of a few departments in our organization, but before starting development heads on, I would love to gather some wisdom from HN.First, what tools are you developing?How do you handle user authentication?Do you develop one single big application for everything in your organization, or few distinct applications, each with its own specific goal?Any specific thing to watch out for?Thanks!

d--b · Accepted Answer

I am developing Jig (https://www.jigdev.com) it&rsquo;s based on Observable and it&rsquo;s meant to create dashboards and apps quickly without much fuss. The aim is to have business specialists write the apps and not html/react which is quite tricky to get right.The product is quite rough right now, but I&rsquo;ve been working with a first client who seem to enjoy it. Happy to demo it.

Jugurtha · Answer

I'm on mobile right now. I'll write something here as soon as I get my laptop. Wait one.

stocktech · Answer

I led a team doing this for 5ish years in a F100. We were the only team and we built it from the ground up. We handled all departments. Some of the bigger ones were customer service related such as letter templates/mailing/printing and a phone system automation/integration. Other apps were used by teams of 2-3 people, such as fraud investigation management, accounting automation, or simple 3rd party report generation tools. Over the years, we developed 20-30 apps ranging in complexity.
To answer your specific questions: 1) User authentication was a centralized service that managed roles and permissions. We integrated with LDAP so that we would only authenticate current employees or contractors, then the service would look up the appropriate permissions. We delegated management of roles/permissions to a business owner in the department and our IT team handled LDAP.
2) Each app was separate - each had 1 app, 1 database, 1 project board. I think the real benefit with this was a simpler mental model while working with the systems, but this came at the cost of managing shared services/packages.
We used frameworks that were more opinionated so that each app made similar assumptions and used the same tooling. I started the team using C# MVC, but we moved to NodeJS on the backend to reduce context switching between FE/BE. The big thing is consistency so that each app's codebase looks and feels the same. When you're jumping between apps, you don't want a day long ramp up period.
Similarly, I made sure all devops type tasks were streamlined. We did CI/CD before our product teams did and had full test suites. Preview environments were setup for developers and users. And everything was documented with guides. We could clone our project blueprint repo and deploy it in 5 minutes. A working CRUD app could be done in a few hours.
One unnecessary thing I choose to do was create SPA frontends. With our blueprint and shared services, it reduced the complexity, but it really gave the team something to learn/dive into. I think that little bit of "sexy tech" went a long way for morale and recruiting.
If I had to do this all over again: 1) I'd do a better job defining the team's value proposition. Those basic CRUD apps could be moved to a no-code platform. The team should be focused on apps where proprietary engineering will benefit the company most. Some of my apps had estimated value-add of $5mm+/year, but we would still get pressure from the execs to make a new app that would save the company 50k.
2) Similarly, I'd make sure my team was separate from rest of the org, as long as it makes sense. When we first got started, I was under a product director. As we grew, we never really found our own space in the org and got pulled in different directions. fwiw, I left the org because they wouldn't promote me.
3) I'd start with each app being separate then move to 1 app per department. We worked towards this as we grew and multiple apps needed to be integrated with each other. I think I moved too late though and our integrations reflected it. Especially as we could have justified a small team for each department, it would have made sense. As a management aside, I wanted to be more agile and form teams around projects - 1 app, 1 database, 1 project board, 1 team. It worked fine, but something something Conway's law.
Some things I think I did right: 1) My engineers did everything - project management, roadmaps, engineering, etc. Even when we had dedicated project managers, my engineers were always in the room because the business doesn't know what they want. We had a number of BIG wins because my engineers could come up with non-obvious solutions. I also gave my team the autonomy to solve the business problem whatever way they saw fit.
2) I hired people who cared more about solving problems than the tech. I encouraged doing more design work than engineering and spending time with our users. This led to better UX, better domain knowledge, and very happy users.
3) I advertised the shit out of our work. Multiple departments have similar work and when we'd build an app that did one thing, I'd go to another department and see if it would help them too. Some of our apps started as a copy/paste and evolved in their own right. I'd also send an email to our senior leaders every time a new app went live with a small description, a gif of functionality, and the estimated value-add. Most of time, we'd add something to our roadmap as a result. I was also good at networking within the org, for whatever reason, so I was able to be proactive in some regards.