Building a Personal Desktop App for Work — A Case for a Fully Local Information Hub

Introduction

Where do you keep all the information you deal with at work?

Docs in Notion, verification queries in a notes app, review status on GitHub, AI questions in a terminal or Claude Desktop... For most people, information and actions end up scattered all over the place.

Lately, I've been taking a different approach: building a personal desktop app for work that lives entirely on my own machine. It's been remarkably comfortable, so I'd like to share the thinking and design behind it.

The Problem: Work Information Gets Heavy When It's "Shared by Default"

When I break down why managing work information feels like a burden, it comes down to three things.

1. Sharing raises the cost of presentation

Work documents demand accuracy and rigor. Once you assume others will read them, you have to polish the formatting, spell out the context, and choose wording that can't be misread. But for information only you need to catch up on, that cost is pure waste.

2. Online services cost you selection, learning, and access

Going through an online service means picking one, learning how to use it, and opening a browser or app every single time. Having that friction wedged into every "let me check that note" or "what was that query again?" is a quiet, constant source of stress.

3. Personal information scatters across projects

Files and documents you want to keep locally — project notes only you need, technical research unrelated to any project — naturally scatter across per-project directories if left alone. And once they're scattered, just finding where you wrote something becomes a chore.

The Approach: Consolidate in One Place, Then Build an App on Top of It

The plan is simple — two steps:

1. Pick one location and consolidate everything there
2. Build a desktop app that reads from that location

I manage my repositories with ghq, so I created a private-documents folder under ghq and consolidated all my personal documents and data there. The desktop app works by reading from this directory.

With this, the entire information network closes within my machine. No presentation overhead for sharing, zero learning cost for services, and access is just opening the app.

What It Can Do: The Features

"Building your own desktop app" sounds like a big deal, but it's really just a collection of views that display the information you need for your work, in the shape you want to see it. Here are the features I've actually found useful.

1. Document Viewer

A view for browsing everything under private-documents in one place. Per-project notes, technical research outside any project — all searchable from the same app. Just eliminating "where did I write that?" also lowers the barrier to writing things down in the first place.

2. A Vault for Commands and Queries

The app also works well as a home for the commands and queries you need for testing and verification.

Every previous method had its problems. Looking things up every time is tedious. A notes app is bad for both search and reuse. Notion means opening it every time, plus painful periodic cleanup.

So I built a UI that lets me save queries and commands freely, organized into per-project areas. The storage is just local JSON — no fancy database needed, so it runs with zero maintenance overhead. Open the app, and the query list for whatever project I'm working on is right there. That alone makes day-to-day verification work much easier.

3. A UI Built Just for You

The big advantage of building your own: you can optimize the UI/UX entirely for yourself.

Use Notion, and you're bound by Notion's ergonomics. Use a Markdown-only service, and your expression is limited to that. In the end, no existing service lets you have things in exactly the shape that works best for you.

For example, I built a custom UI for understanding database table structures. Having a view where I can create and check ER diagrams without friction makes understanding schemas and reviewing designs dramatically faster.

4. CLI Integration: Making BigQuery and Storage Data Readable Locally

This approach pairs especially well with workflows that pull information from BigQuery, Cloud Storage, and the like via CLI.

At the end of the day, all you're doing is deciding how to combine and present information obtained from the CLI, locally. As long as you can pull development data (not production data), you can build whatever UI you like on top of it.

For example, data that's a wall of UUIDs — normally impossible to make sense of — can be combined with local mapping data and displayed in a human-readable form, in a UI you built yourself. That's an experience no off-the-shelf service can ever give you.

5. Tracking Review Status

A view listing the reviews you've requested on GitHub and the reviews requested of you is also worth building.

Sure, you can see this by opening GitHub — but the value is in having it consolidated into the same desktop app. No app switching; it's right there whenever you need it. You get a natural flow where review status catches your eye while you're checking docs or queries anyway.

6. AI Agent Integration

Since it's a local app, you can invoke your local CLIs (Claude Code, Codex) directly. And you can switch freely between agents within your existing subscriptions — that's a real plus.

For example, with a "send a quick question to Claude" button, you can fire off a one-off review prompt without opening a terminal or Claude Desktop. Beyond reviews, routine tasks like creating PRs can be automated behind a single button.

Here again, "building it with the UI/UX you want" pays off. Even your interaction flow with AI can be designed around your own workflow.

The Key Design Decision: Separate "Per-Project" from "Shared"

The design lesson I learned from actually building this: separate what belongs to each project from what's shared across all of them.

• Per-project: queries, commands, project-specific documents and mapping data
• Shared: review status checks, AI agent integration, cross-cutting technical notes

This separation comes naturally when you build your own — and that's its strength. The more projects you're involved in, the more this setup pays off. As projects multiply, the shared features carry over as-is; you only add the project-specific areas.

How to Run It: Don't Over-Build Upfront

One more important thing: don't build it all out from the start.

When you need a feature, build it right then. That's all. So yes, you start with almost no features — and that's fine. As you work day to day, the "it'd be nice to have this" moments accumulate naturally. When one comes up, just build it roughly and see how it feels in use.

It's for you alone, so no requirements docs, no polish needed. Build it rough, grow it through use. That casualness is another advantage unique to building your own.

The Downside: Feature Oversupply

I've been singing its praises, but there is a downside.

Being able to add features endlessly makes things convenient — but it also leads to feature oversupply, which makes cleanup painful. Precisely because building is so easy, unused features and half-finished views pile up. Be prepared to periodically review what you're no longer using.

Summary

• The weight of managing work information comes from "presentation for sharing," "service selection/learning/access costs," and "scattered information"
• Pick one location (mine is private-documents under ghq), build a desktop app on top of it, and your information network closes locally and gets lighter
• Documents, query vault, DB structure visualization, CLI integration, review status, AI agent integration — all consolidated in a UI shaped exactly how you want to see it
• Per-project and shared features separate cleanly, so the more projects you juggle, the bigger the payoff
• Don't over-build upfront; build when needed and grow it through use — but watch out for feature pile-up making cleanup painful

In the end, day-to-day development work is a constant cycle of combining the information you've gathered and deciding how to look at it. Instead of bending that to fit generic services, build it as your own personal app, entirely local. The more projects you're involved in, the more it's worth a try.