What I’ve Learned Building Internal Tools

Published: May 2025 — ~5 min read

Most internal tools are built to check a box. Some manager needs a “dashboard,” so the team slaps something together. But when you’re the one actually building and maintaining the thing—especially for people you know will use it daily—it hits different.

I’ve built internal tools for real use: document management, fleet tracking, user onboarding, SQL data transformations. Some were for side projects, some for personal tools, others just to solve a messy workflow that nobody else wanted to touch. Here's what I've learned along the way—no buzzwords, no inflated case studies, just the real stuff.

1. Features Don’t Matter if No One Uses Them

You can have six tabs, fifteen modules, and a shiny dashboard—but if people don’t come back to use it, it’s a fail. I’ve found that even one feature, done right, is better than five unfinished ones.

In one tool I built, the “upload document” form ended up being the most used screen. Not because it was complex—because it solved a pain point that came up daily. That’s what mattered. Not the framework. Not the login screen design. Just that one task.

2. Your Users Are Not Developers

Sounds obvious, but it’s easy to forget. You can’t assume people understand validation messages, know what JSON is, or care about how you structured the backend. They want clarity: “Did it save?” “Do I need to upload this again?” “Where do I click?”

The more I built for non-technical users, the more I trimmed the fat. Clear labels. Feedback. Fewer clicks. Less guessing. Every time I over-engineered a flow, it came back to haunt me.

3. You’re Going to Rebuild It — Build It Loose

Almost every tool I’ve built has changed over time. Sometimes that’s because someone actually started using it and needed more. Other times, I changed my mind halfway through and realized a different layout or logic made more sense.

So now I build loose: config-driven logic, components I can drop into other views, document types defined by enums or lists I can update later. I don’t always overengineer it—but I leave space for change. Because change is inevitable.

4. Authentication Will Be 10x More Annoying Than You Think

If you’re working with roles, permissions, or anything gated—it’s going to get messy. I’ve done this with Blazor (using .NET Identity) and WPF (with simple role files), and no matter how clean you try to make it, you’ll find weird edge cases. “Why can’t this user see the button?” or “Why did this one bypass the form?”

What’s worked best for me: start simple, bake in logging early, and assume you’ll refactor it twice. Secure things at the route level, but also in the UI, and test with at least two different real users. Don't wait until "later" to think about access logic.

5. File Uploads Will Break—Plan for It

I’ve built a few tools now where users upload files: PDFs, IDs, Excel sheets. Doesn’t matter what stack you’re using—it’s always a pain. Uploads fail. File names clash. Metadata gets skipped. Users click twice.

What helped: showing a clear “Upload complete” message, storing uploads with unique IDs, and logging every upload attempt. Also: give people a history tab. If someone thinks they already uploaded it, give them proof.

6. Internal ≠ Ugly

Just because something is “internal” doesn’t mean it should look like a Windows 98 utility. I’m not talking about fancy animations—I’m talking about spacing, alignment, typography. Users want clarity, not clutter. If your UI feels calm, they’ll keep using it.

Even in my WPF apps (yeah, desktop still has its place), I added simple themes and spacing helpers just so the UI wasn’t miserable. It matters more than you think.

7. Logging Is Your Best Friend

Seriously—log everything. You don’t need a full telemetry suite, just a file or database table that tells you what happened: who clicked what, when, and what broke. It’s saved me hours when debugging permissions, broken uploads, or weird data cases.

8. Internal Tools Can Be Your Best Portfolio

I don’t show off these tools for design awards. But I do show them to future clients and employers. Why? Because they show I can build something real, from scratch, that works. Even if it’s not public, it proves I understand systems—not just UIs.

I’ve built tools to manage compliance, import data, structure documents, and onboard employees. They’re not flashy, but they’re functional—and they show I can design, code, and ship something people can rely on.

Internal tools are where I learned how to solve real problems, not just write code. You don’t need a perfect UI or a trendy stack. You just need to care about what people actually need to get done—and build something that helps.