It works in your Claude

You build something genuinely good inside your Claude. It reads your files, drafts the email, opens it on your screen, remembers your context, picks the right model, calls your tools. It feels like a product. And you think what everyone thinks at that point: I'll just ship this, or hand it to a colleague, or turn it into an app.

Then you try -- and discover how much the client was doing for you.

The Doping

You can be extremely productive inside a desktop or code client without noticing how much it carries. It handles context for you. It connects your tools via MCP. It picks the model. It can trigger things on your computer -- open a folder, drop a draft into your regular email client. Inside it, you feel like a genius.

That's the doping. And like all doping, you don't see it until it's taken away.

The moment you step outside the client -- a web app, an API, something a non-technical colleague needs to run -- all of that is gone. And you have to build it all deterministically yourself.

The Example That Reveals It

Take the email draft that appears on your screen. It feels like the core feature of what you built. But it only works because the desktop client controls your computer and can ask the operating system to open a draft. A web app can't trigger that. The capability that felt like yours was the client's.

The same goes for skills -- the reusable instructions that make your whole setup sing. You can't just expose them via an API. They live in the vendor's desktop and backend. There are server-side variants, but they're a fraction of what you do locally.

The pattern repeats: what made your solution feel finished was largely things the client gave you for free -- things that don't come along for the ride.

The Distance You Don't See

What looks shippable in your own Claude is a demo dressed as a product. The distance from "works for me, here" to "works for anyone, there" is nearly all the engineering -- and it's invisible as long as you're doped.

This is not an argument against building in Claude. It's still the best place to think and prototype. It's an argument against confusing the prototype with the product, and against quoting a timeline as if the hard part is done when the hard part hasn't even started.

The client is doing more for you than you realise. Knowing exactly what it does -- and what you would have to rebuild without it -- is the difference between a demo that impresses and a product that ships.

See also: The impressive and the billable are not the same thing (Delivery).

Mindtastic on skills across surfaces and their limits -- Skills as Governance.