Building Internal Tools That People Actually Use

Most internal tools suck. They're slow, confusing, and nobody wants to use them. Then leadership wonders why everyone's still using spreadsheets and Slack threads.

The problem: engineers build internal tools like side projects. They should be built like products.

Talk to Your Users First

Spend time with the people who'll use the tool. What's their current workflow? Where do they get stuck? What manual work eats their day?

I've built three internal tools. The one that got adoption was the one where I spent a full day shadowing the sales team before I wrote a single line of code.

Speed and Polish Matter

An internal tool that's 50% slower and 20% more painful than the spreadsheet they're using gets abandoned immediately.

Make it fast. Make the UX obvious. Add loading states. Add error messages that make sense. Polish the form inputs. Small details create a tool that feels intentional instead of like an afterthought.

Reduce Friction to Adoption

• Deploy it where people already live (Slack, email, browser bookmark)
• Make onboarding instant (single sign-on, zero setup)
• Show obvious ROI in the first 30 seconds
• Respond to feedback in hours, not weeks

Internal tools are one of the highest-ROI things you can build. But only if people use them.