Why we built GetResolved (and why it lives in your terminal)

I'm a solo founder who ships a lot. On any given week I'm working on several products at once, mostly from my terminal, often with Claude Code in the loop. That's the context for everything that follows - because the moment I went looking for customer support and issue tracking tools, nothing fit the way I actually work.

This is the story of what was broken, what I built instead, and how it shows up in a normal day.

The Problem: Per-product pricing, and a gap between support and code

Two things, really.

The first was pricing. Every tool I looked at charged me per product. Twenty euros here, twenty euros there. Fine if you're a team with one product. Brutal if you're one person with ten. Some people I know are running a hundred small projects. There is no version of "twenty euros per product per month" that works for that life. The pricing assumed a world that doesn't exist anymore - one where one team meant one product. In the AI era, one person can credibly run a portfolio, and the tooling hasn't caught up.

The second thing was deeper. Existing tools split customer support and issue tracking into two separate worlds. A customer writes in with a problem. Someone reads it, translates it into a ticket, files it in the issue tracker. The developer picks up the ticket - but they never see what the customer actually said. They see a sanitized version. A summary. A guess at what the real problem was.

That gap is where misunderstandings live. The developer ends up fixing something adjacent to the actual problem, or building something the customer didn't really ask for. Over time, the product drifts away from the people using it.

I didn't want either of those things in my work.

Chat with customers, ship the fix, tell them it's done

The shortest way I can describe GetResolved is this: chat with customers, ship the fix, tell them it's done.

That's the whole thesis. Customer support and issue tracking aren't two separate jobs that need to be handed between people. They're one loop. The conversation, the work, and the follow-up are the same motion. When the loop is closed, customers hear back about the things they asked for - in their language. When it's open, things rot.

Pricing follows the same idea. You don't pay per product. You pay based on how many conversations you actually have. If you have ten products and twenty conversations, that's cheap. If you have one product and ten thousand conversations, that's a real business and you can afford it. The model scales with the work, not with how many side projects you happen to have running.

Issues in the terminal, conversations in Slack

This is where the terminal piece comes in, because the loop has to live somewhere - and for the way I work, it lives in two places at once.

Issues and work happen in the terminal. You can run the whole of GetResolved from the CLI without ever opening a web app. That matters because development has moved into the terminal. If your day is "talk to Claude Code, ship something, move on," asking you to break that flow to go check a support dashboard is asking you to lose the thread.

A few things become natural once support and issues live where you already work:

I'll sometimes build something that came straight out of my head and never made it into the issue tracker. So I tell Claude Code to submit the issues to GetResolved and mark them done. It might log five or ten issues at once and close them. Now I have a record of what I shipped, without having stopped to write it down.

I can also load up the open issues and see which one is being asked for most. And when I say "fix this issue," the CLI pulls up the actual customer conversations tied to it - not a summarized ticket, the real messages. Whatever's doing the fixing understands what the customer was actually asking for, not someone's translation of it.

It's powerful, and it's easy. That combination is rarer than it should be.

Live conversation happens in Slack. Doing real-time customer chat in a terminal would be miserable. Nobody wants that. Your customers aren't in Slack - they're writing in through whatever support channel you've set up, like a widget on your site. Their messages get routed into Slack, where you reply naturally. The customer just sees a normal support conversation. You get to handle it in a tool you already have open.

So the split is clean: live human conversation in Slack, where conversation belongs. Calm, controlled issue management in the terminal, where work belongs. Both feeding the same loop.

Seeing the customer's real words keeps the work honest

There's a thing that happens when the developer never sees the customer's actual words. The work starts to feel abstract. You're closing tickets instead of helping people. Over enough time, the whole product drifts.

When you see the real message from the real person who's asking, the work feels different. It feels like it matters, because it does. Yes, sometimes that means seeing customers be blunt or frustrated - but I'd rather have that than a polished translation that hides what's really going on. The closeness is the point.

That's what the loop is really for. The pricing model makes it affordable to run across many products. The terminal-first workflow makes it fit how solo founders actually work. The Slack integration makes the live side feel native. But underneath all of that, the reason GetResolved exists is to keep the people building things and the people using them connected to each other.

Early days, first customers, building in the open

GetResolved is in its early days. I'm working with the first customers right now - people who, like me, are running multiple products and want a way to stay close to the people using them without drowning in tooling costs.

There's still a lot to figure out. How to communicate the loop cleanly on a first visit. Which pieces of the product land hardest. Where the pricing model needs to flex as people use it for real. That's the work of these first months, and I'm doing it in the open with the people who are coming on board now.

What I know is that the math works, the workflow works, and the way it keeps me connected to my customers across all my products is the thing I didn't have before. If you work the way I do, I think you'll feel that too.

That's why GetResolved is here.