Build It for Yourself: Swift Widgets and MCP Instead of Admin Panels

I made my own desktop widgets this week.

Right-click the Mac desktop, hit Edit Widgets, and there's a little set of mine sitting next to Apple's. A world clock with West Coast, East Coast and wherever I happen to be, with the weather for each. My spending and income for the last 30 days across all my books. My liquid investments, net of what I've borrowed, with an allocation bar so I can see at a glance if something drifted.

None of it is in an app store. It has one user. It does exactly what I want and nothing else.

I wrote about this idea a few weeks ago in Web 4 is about building your own systems. Software for an audience of one. This post is about two habits that came out of actually living that way: I build native when I build for myself, and I stopped building admin panels.

If all you have is a hammer

The widgets themselves aren't the interesting part. The interesting part is that it took me this long to build them.

For most of my career, learning a technology was a big investment. You spent months, sometimes years, getting good at a stack. And you had to, because the learning didn't stop once the thing worked. When something broke at 2 AM, you were the one who had to fix it. You needed to know the framework well enough to debug it, read its weird error messages, and know which Stack Overflow answer was wrong. So you picked a lane and went deep.

My lane was the web. I've built a lot of web apps. Frontends, backends, dashboards, APIs. And when you've built a lot of web apps, every problem starts to look like a web app.

If all you have is a hammer, everything looks like a nail.

Want to see your finances? Build a web app. Want to track your rental properties? Web app. Want a to-do list, a clock, a status page? Web app, web app, web app. Spin up a server, add a login, deploy it somewhere, open a browser tab.

The problem is that a browser tab is a terrible place for a lot of information. Nobody looks at it unless they go looking. It lives behind a bookmark, behind a login, behind ten other tabs. The stuff I actually want to know, like what I spent this month or what time it is for the people I work with, belongs somewhere I already look. The desktop. The menu bar. The home screen.

I knew that. I just never went there.

A bridge too far

Native Mac development always felt like a bridge too far. Not because it's impossible, but because the math never worked out.

I wasn't building anything professionally on the Mac. So learning Swift, Xcode, code signing, entitlements, WidgetKit and all of Apple's rules would have been months of work for a few small tools only I would use. And then the first time something broke, I'd be stuck debugging a platform I barely understood. It was easier to just build another web app. That's where my skills were.

That's the old frame of mind: the cost of learning decides what you build. You don't solve problems with the best tool. You solve them with the tool you already paid for.

AI broke that math, and the strange part is how long it took me to notice. The tools were good enough months before I changed my habits. The hard part wasn't technical. It was the mental block. I still had the instinct that native was "not my area," the same way some people still assume they can't build software at all.

What changed it was just trying. I asked for a widget. It worked. Something broke, and instead of being stuck, I described the problem and we fixed it together. Turns out the widget system caches each extension by its build number, so if you don't bump the number every build, macOS keeps showing your old widget forever. I would have lost a weekend to that a few years ago. Now it's a note in a README.

You don't have to be an expert in a platform to fix things on it anymore. You just have to understand what you want and be willing to poke at it.

The fun part

What surprised me is how much I enjoy it.

There's something satisfying about changing your computer at the system level. Not a website you visit, but the machine itself. My clock widget figures out what city I'm in with CoreLocation. I tried IP geolocation first and it put me in Montreal, because of my VPN. Wi-Fi positioning doesn't care about the VPN. That's the kind of detail you only run into when you're working with the hardware, and it's fun to run into it.

It also just fits better:

• It lives where I already look. A widget doesn't need to be opened. I see my numbers because I glanced at my screen, not because I remembered to check.
• It feels like it belongs. System fonts, dark mode, the same look as everything else on the Mac. It's part of the computer, not a page sitting on top of it.
• There's nothing to host. No server, no domain, no login page, no auth to get wrong. It's an app on my machine.

I've built a few of these now. A menu bar app that warms my screen at night. Personal finance apps for desktop and iPhone. A tasks app. Now widgets. None of them would have existed under the old math. Each one is small, and each one is better than anything I could have downloaded, because it was made for exactly one person.

The lesson I keep relearning: the skills you have shouldn't decide the shape of the solution anymore. The problem should.

Stop building admin tools. Build MCP tools.

The second habit is the one I think more people should steal.

Every website I've ever built eventually grew an admin panel. Log in, see a table, click edit, change a field, save. Build a form for creating posts. Build a page for approving things. Build a dashboard to see what's going on. It's a lot of work, and it's work nobody enjoys, and the result is a pile of screens I only open when something breaks.

I don't do that anymore. Instead of giving myself admin tools, I give myself MCP tools.

MCP, the Model Context Protocol, is a standard way to hand tools to an AI. You write a small server that says "here's what you can do": list posts, create a draft, look up a transaction, log a repair. Then any AI that speaks MCP can use it. Claude Code, the Claude app, and more and more of the other tools I use.

So now my personal systems each have an MCP server:

• My blog. This post exists because I asked for it. The site has an MCP that can list my writing, create drafts and give me a preview link. There is no admin page.
• My finances. Transactions, holdings, receipts, taxes, all behind tools an AI can call. I ask questions in plain English instead of clicking through reports.
• My rental properties. Every appliance, model number, service visit and work order. When a contractor fixes something, I describe it and it gets logged.
• My tasks. My bots and I share one board, and they move work through it with the same tools I do.

Here's why this beats an admin panel.

The interface is a conversation. I don't need to design a form for every action, because the AI is the form. "Show me what I spent on the rental this year" doesn't need a report page. It needs a tool that returns transactions and a model that can add.

One server, every AI. I build the tool once and it works in my terminal, on my phone and in whatever AI tool I pick up next year. An admin panel is locked to the one website it lives on. An MCP server goes wherever I go.

The tools compose. An admin panel can only do what that one site does. In a conversation, the AI can pull a receipt from my email, find the matching transaction in my finance system and attach it, in one go. Three systems, no glue code.

It's less to build. A tool is a function with a description. No layout, no table component, no pagination, no CSS. I spend my time on the part that actually matters, which is the data and the rules.

And here's the part that made it click for me. Those desktop widgets? They don't have their own backend. They call the same finance MCP server my AI does. One read-only token, the same tools, the same answers. The MCP server isn't just an AI integration anymore. It's the API for my life, and the widget is just one more client sitting on top of it.

So the pattern looks like this. Data lives in a system I own. The system exposes MCP tools. AI uses those tools when I want to ask or change something. Small native apps use the same tools when I want to glance at something. No admin panel anywhere.

DHH went a step further

If you want to see this instinct taken all the way, look at what David Heinemeier Hansson did.

DHH created Ruby on Rails, the framework that taught a generation of developers that one person could build a whole web app. Last year he left the Mac and built his own operating system setup. He calls it Omarchy. It's Arch Linux with the Hyprland tiling window manager and a whole set of his opinions baked in: the apps, the keyboard shortcuts, the themes, the tools, the way everything fits together. One install and you've got his machine.

The name gives it away. Omakase, "I'll leave it to you." It's the same idea as Rails: strong defaults, picked by someone who cares, so you don't spend your life configuring things.

That's the same move I'm making with widgets, just at a much bigger scale. I didn't like how a few things on my desktop worked, so I built my own widgets. He didn't like how the whole computer worked, so he built his own computer experience. And then he shared it, and a lot of people turned out to want the same thing.

I'm not switching to Linux tomorrow. I'm pretty happy inside Apple's walls, partly because Swift makes building for myself so easy now. But I love that Omarchy exists, because it proves the point. The layers that used to feel fixed, the OS, the desktop, the admin panel, the app you were supposed to download, aren't fixed anymore. If you care enough, you can rebuild any of them around how you actually work.

Start with one

If you want to try this, pick one thing:

• A number you check every day. Make it a widget.
• An admin page you hate. Delete it and write an MCP tool instead.
• A platform you've always assumed was "not your area." Build one small thing on it anyway.

Build it for yourself. Let the problem pick the tool, not your resume. Give your AI the tools instead of giving yourself the screens.

The computer is starting to feel like mine again.