Four months of running two macOS apps

A while ago I wrote Off the name game, where I laid out why I chose to widen my range and become a developer who can stand on his own, instead of chasing a name-brand company. I started my career as a backend engineer, but the label on the role keeps shifting. Some people call it "product engineer," others "AI engineer." I had to look up what "harness engineer" and "FDE" even meant. The phrase that surfaces in my own head is "complexity manager." I have no idea what my title will be three years from now.

In an era where nothing is settled, the decision to widen my range as a developer looks, in hindsight, like a pretty good one. The next shift might come faster still. Even with a full-time job, "structural unemployment" could land on my doorstep tomorrow. So I needed to keep something development-shaped in my hands during my off hours, and I figured I might as well build indie products.

devglow and todoglow are what I want to walk through here. If they become a side income, great; if not, they still widen my range and thicken up knowledge I'd let go thin. That's exactly why I deliberately picked Tauri and took on two macOS apps. This is a record of running both for four months.

How devglow and todoglow began

They're both macOS menu bar apps. devglow lets you see the state of your dev projects — processes, logs, MCP connections — at a glance from the menu bar. todoglow is a keyboard-first app for creating and closing todos straight from the menu bar. In my head I bundle them together as "Glow Suite." (I actually sell the two together as a discounted bundle.) It's not a monorepo or anything that tight; just a pair that borrows each other's design tone and component patterns.

devglow came out of a daily pain. When you run several sessions of AI coding agents like Claude Code or Cursor at once, the processes they spin up on their own start colliding with ports your servers are already holding, and the whole flow tangles. I'd seen indie apps like PortKiller, but the look didn't sit right with me, so I figured I'd build one for my own use. Since I tend to stare at process state and logs a lot while developing, I threw in a log viewer while I was at it. (I've written about this thread once before, in devglow 1.5 — sidebar and split panes.)

todoglow split off by accident. My girlfriend looked at devglow's theme palette and said it was lovely, that it was a shame it was just for developers. I was wrapping up the devglow MVP around then, so I wrote up the design separately and built a todoglow MVP. Getting a UI I'd only ever pictured in my head into words turned out to be hard; I spent maybe 70% of my Claude Code sessions just refining the UI.

Wiring MCP into devglow was close to inevitable. A session with an AI coding agent almost always has a local server or two running alongside it — a Next.js dev server, an API, that sort of thing. For today's workflow, the agent needs to be able to start, stop, watch the ports and read the logs of those servers directly, and MCP is the doorway to that. devglow was already managing those servers, so all that was left was to open the door to the agent.

todoglow was a different story. It's a precise, hands-on ritual — duck in with a keyboard shortcut, write one line, close it — and I went back and forth for a long time on whether letting an agent in was even right. The way I work now is to keep several AI conversation sessions running in parallel. Like a cook with pots on several burners, stirring each in turn, every session sits at a different stage. And yet a person's focus is, in principle, singular. One person can't have two things "in progress" at the same time. So after a lot of deliberation I kept the limit of a single "in progress" todo. I judged it fit the human mental model better. What I did instead was separate the todos a user writes from the work an agent writes. What the agent writes piles up in its own "AGENTS" panel, and the user can promote one of those into the "in progress" slot.

Right after launch — so there's demand

When I dropped the beta in February 2026, the plan was to run that beta for a few months. I figured demand was something I could ask slowly and get answered slowly. I was still deep in figuring out what to do for a license model. (I had LemonSqueezy as the front-runner, but they rejected me in review, and Polar¹ took me in.)

On February 3, right after launch, I put up my first post on Threads. "Out of a million todo apps, none of them were to my taste, so I made one. For people who sit at a Mac more than a phone — I tried to keep that springy keyboard feel intact." Within 24 hours, close to three thousand people landed on the page. Looking at the OS split, about one in ten was on macOS. I read that not as raw traffic but as roughly 300 of my actual target audience showing up inside it.

The comments were as clear as the numbers. Lines like "a todo app that floats over my Mac all the time — exactly what I wanted" and "feels like a step up from Raycast's focus mode" came in. I liked that a tool a developer made gets recognized by other developers and designers. A few days later, my first r/macapps post drew the same kind of response in the comments. Strangers had been waiting for a tool like this inside their own workflow.

Some people sent long, detailed feedback along the way, and I remember them. The comments and emails laid bare just how rough an MVP it was. But the very act of taking the time to write it out was the most honest response I could've gotten.

That told me this was a market I could move through a little faster, so I dropped the idea of dragging out a free-only beta and rushed to bring in the license model.

That door I mentioned — opening devglow up to the agent — I got my hands on it around this time too. In the first week of month one, the code that lets an AI agent manage processes through devglow went in, and a few days before that I'd finished making the GUI app inherit the shell env. I wanted to get the detail right: an AI agent only really works if it runs in the same environment as the shell the human has in hand.

MCP was the first protocol I'd ever worked with. But I didn't study up before diving in. The place to use it surfaced first, and I picked up whatever I needed as I went, bolting it on.

Month two's redesign, and month three

Late in month two, I tore devglow up into a sidebar + split-pane structure. Before that, processes were just a flat list. Around then, using cmux myself, I realized that the mental model developers are already comfortable with — tmux, Ghostty, note apps all work that way — was the sidebar and the split pane. What I wanted was for the tool I built to feel familiar, at least in how it's operated. In the same vein, I moved the category name twice: "Dev Server Manager" → "Process Manager" → "a tool you use alongside tmux/cmux."

Over the same stretch, todoglow kept climbing too. I shipped minor versions almost weekly, from v1.6 through v1.8. A command mode that sends a todo straight to Apple Reminders, a screen in the archive that shows monthly stats as receipt cards, things like that.

The countdown timer also went in around then. There are dozens of Pomodoro apps, but most of them shove the remaining time at you as a big number. That number is exactly what distracts me, so I built a timer with the clock removed. Instead of digits, the remaining time shows only as a faint grid pattern filling up, and you get a notification when it ends. I built it that way because that's how I wanted to use it.

The harder technical work was mostly on the devglow side: process management, shell env inheritance, log streaming, MCP. And yet the one I was most attached to, using it myself every day, was todoglow — which is why it's also the one my hands kept reaching for.

Then in month three, the data stalled. mcp_connect: 6. New trials: 4. In my notes I wrote, "the DG pipeline has dried up." Around then there were plenty of higher-priority things on my plate, and the time I spent looking at the data shrank along with it. For about six weeks, I'd more or less taken my hands off new feature work on devglow. CS replies kept going the whole time, though.

Month four — the data six weeks later

Late in month four, I looked at the data again. Month three's 4 new trials had become 14 in month four, MAU went from 15 to 28, and MCP connection events from 6 to 55. devglow's own commits went from 6 in month three to 60 in month four. I'd gone a long while without looking at the data because I was buried in code, and in the meantime the flow had turned over once.

The jump in MCP connection events from 6 to 55 isn't something I read too much into on its own. Part of it is that I hadn't wired up analytics properly in the early versions, and there were at least two cases where I personally walked someone through MCP usage in a support thread. Quantitative signals alone won't catch an inbound path like that.

Let me put down one example of how that walkthrough went. I traded emails a few times, starting early in month four, with a senior PM who used devglow. The requests were things like: the selection in the log area keeps clearing, the copy/download flow is awkward, the search/filter could be stronger. I took them in and shipped them step by step in v1.5.13 and v1.5.16, and at the end of a reply I tossed out, lightly: "If your flow is reading logs directly, devglow has an MCP server running, so you can handle them straight from Claude Code or Cursor. Say 'spin up the local server' and the agent starts it for you; say 'read that server's logs and tell me if there are errors' and it reads them right away." Going through the requests, I'd sensed a touch of MCP would resolve them naturally.

A few days later the reply came back. "The MCP is AN ABSOLUTE GAMECHANGER!! The number of times I've had to create custom logging, filter for it select, copy, paste – back and forth. That's just gone!" Me writing "this is a gamechanger" and a user writing it to me himself are two different things.

This is where I looked back at the month-three verdict. It wasn't that the bet was too early; it was that natural adoption takes time. There's a gap between someone who uses an AI coding agent and someone who has installed and configured an MCP server into it themselves, and the more accurate picture is that the people who've crossed that gap are accumulating slowly.

The target hypothesis got readjusted along with it. I built devglow with developers who have the traditional habit of reading logs directly as my mental target. But quite a few of the users who actively send me questions or feedback over email don't come from a development background. (They're the crowd often called "vibe coders," a label I don't find quite accurate, so I tend to avoid it.) Even without touching code directly, there's a separate demand to see how a process lives and moves. You can't catch this kind of thing up front in your head; it only showed up long after I'd put the product into people's hands.

On the todoglow side I piled on one more big piece in month four. Bouncing between two Macs myself, I came to badly want sync. Questions about whether you could use it on mobile trickled in from users too. So I packed multi-device cloud sync into v1.9 and shipped it. devglow's data drying up in month three and my hands returning to todoglow in month four happened inside the same two months.

To put the numbers down together: todoglow has 86 trials cumulative, with 20 converting to a license (23.3%), and 321 cumulative devices. devglow has 48 trials cumulative, 14 licenses (29.2%), and 85 cumulative devices.

Users who run both apps: 22. Since I use both myself, I'd hoped some cross-sell would happen, but I didn't expect much. When I'd shown devglow to developer friends around me, there wasn't much of a reaction. Yet looking at the data, it turned out to be quietly carrying its weight as a steady seller.

While running them — the decisions

Running the apps was one decision after another. Across the two apps over four months, I made something like a hundred decisions, big and small: pricing, trial length, marketing channels, the CS response cycle, judgments about what to trust and what to tear up inside the tech stack. None of them settled in one shot.

1. Technical judgment — which abstraction not to trust

Right after launch I scrapped Tauri's built-in auto-update plugin on both apps and switched to the Sparkle² framework. For an app installed in macOS /Applications, the built-in updater hit a silent failure over admin-permission timing. The download succeeded, but the actual app swap didn't happen.

The way I reached Sparkle was through being a user myself. I use Fork (a git client) a lot, and I'd always had the impression its update flow was clean. "What library is this thing using?" I looked it up, found Sparkle, and got curious about applying that approach to my own apps. (Only then did I realize how many macOS apps use it.)

An indie full-stacker has to decide, every single time, which abstraction to trust and which to touch directly. I tore both apps up on the same day.

2. Pricing — the price kept confusing me

I meant for it to be paid from the start. I knew that if you start free, free tends to stay free forever. I grandfathered my 23 beta users in, free for life. "The people who showed up when I dropped the beta — I want to hold onto them even as it goes paid." It was a decision that left revenue on the table, but it felt right. Free coupons made up 57% across the four months.

The pricing model itself wobbled. At one point I even tried a subscription, then rolled it back to a one-time purchase.

Trial length was the same. At the very start I demanded payment up front with no trial, which drew pushback, so I gave 7 days next. Then, after I put the monthly-stats screen into todoglow, I doubled it to 14. A week is too short to actually watch the stats accumulate, and I judged that you have to get a taste of that before it leads to a purchase.

It didn't sell well in Korea. No surprise there. (That's part of why I built it in English only in the first place.) Purchases came in not just from the US but from Europe too. It's a market where you can't picture in advance who buys from where. Polar's cumulative revenue over four months: $451, 90 orders, a 25.6% checkout conversion. Not a big number, but a signal that the license model is, at least, turning over.

3. todoglow per-slot themes — where a user request met my own curiosity

A todoglow user sent in a request asking whether you could give each slot a different color/theme. todoglow has five slots, ⌘1 through ⌘5 (⌘1 is the All view, ⌘2–⌘5 are separate lists), and until then the theme was a single global one. Every slot shared the same accent color.

Hearing it out, I thought a different color per slot would split them apart visually and be more fun. It was also an approach I hadn't really seen in other todo apps. The fork in the question, though, was whether to let the user pick each slot's color directly or have different colors get assigned automatically, so in my reply I asked about both options together.

Technically, what followed was a refactor of the theme from a single global value into a per-slot mapping. The flow was to treat global-theme-vs-slot-theme as a "scope" and apply it consistently across the codebase. Overlays that belong to a slot context I unified under the main scope, and places like the archive footer I cleaned up to follow the slot theme too. I added a per-slot theme picker to the Settings → Display tab and shipped it. It might have been a request the user tossed off, but the more I thought about it the better the idea got, so I spent a few days running it in my head before setting aside a day to build it.

4. The rest — marketing, CS, and the small decisions in between

For marketing channels I ran Reddit, Threads, even Shorts/TikTok, but I still don't know whether any one channel holds up over the long run. Reddit was a surprisingly good fit. My first r/macapps post got a better response than I expected, so devglow's core external channel naturally gathered there. Threads had movement in Korea, but it didn't lead to purchases. The audience and the paying market sat in different places. I walked into Product Hunt not knowing it's a meta-game of lining up a hunter and timing the launch, and starting the day after launch I began peeling the PH badges back off. Honestly, for two months I drifted along not quite knowing what I was doing. So I set my own deadline on marketing and cut it there. Then I came back to builder mode, and that felt so, so good. (read: the marketing was that brutal)

On the CS side, a French user on an AZERTY keyboard reported that the shortcut hints didn't match his layout. Since todoglow is a keyboard-first app, I'd designed the shortcuts around physical key position rather than the letter. So the behavior itself is fine on any layout, but the hints shown on screen were pinned to the QWERTY letters, which made them look like the wrong keys to an AZERTY user. It was a blind spot born from trying to hold the concept. Within a few days I added QWERTY/AZERTY/QWERTZ layout selection to settings and shipped it, so picking your own layout makes the hints show correctly. A keyboard problem I'd have never touched in my life.

Operating mode, and what's next

Running a service like this while holding a full-time job wasn't easy. It's fixing errors and adding features after you get home. For the first month and a half after launch I put effort into marketing too, and that was genuinely hard. After that, work and personal life pushed it down, and I got to it less. And yet the apps were tracing their own small cycle. One night, while I was asleep, someone in the UK bought a copy; one recent weekend, the first purchase came in from China.

Releasing an app as an indie developer has something in common with an artist putting out an album. It's fun to watch how people react to what I made, to get feedback one line at a time. People who wanted the same thing I did — wanted it enough to pay, even — are scattered all over the world. It makes me want to put out another album.