Why Not Just Do It in Claude?
A four second test for whether your product should exist, and what it did to mine.
There is a test I run now. Someone describes a piece of software they are building, and I ask, without snark: why not just do that in Claude?
I mean it literally and I mean it kindly. It is not a gotcha. It is the fastest way I know to find out whether a product has a reason to exist, and it takes about four seconds. For a growing number of products, nobody at the table has an answer.
The question is not really about Claude. Claude is only where it happens to point right now. Underneath is the question every generation of builders eventually gets asked, usually by the market, usually late.
The ladder
If you are building hardware, the question is: should your hardware exist, or should it just be software on a computer someone already owns?
If you are building a mobile device, the question is: should your device exist, or should it just be an app on a phone someone already carries?
And now: should your product exist, or should it just be a tool in Claude?
It is the same question three times. Each rung is one a previous generation of builders had to answer honestly, and on each rung the honest answer has usually been no. That is not a criticism of anyone who answered yes anyway. Some of them were right, and the ones who were wrong were wrong in public, at expense, which is braver than most of us manage.
What is different about the third rung is only that the platform arrived without anyone agreeing it was one. ChatGPT alone was at 900 million weekly actives in February 2026. That is not a feature surface, that is where people are.
I think the chat window is a new computer. The chatbot is a new interface, the best interface has always been no interface at all, and that interface's time has finally come.[^krishna]
The claim is not the useful part. The test is.
Where the answer is still yes
A test that can only come back one way is not a test. The answer is yes more often than my own argument would like.
The clearest case is input that is continuous and spatial, where prose is a bad container. Geospatial platforms are the example I keep returning to. Drawing a polygon on a map is not a shortcut for a sentence. It is a thing no sentence does well. The precision lives in your hand, over a surface where a small movement means a large difference, and describing that shape in words costs more than drawing it and produces a worse result. The map is not a picture of the data. The map is the control.[^1997]
The same holds anywhere the interface cost is paid once and the articulation cost is paid every time. If you do something four hundred times a day, a purpose-built surface wins on rhythm alone, and no amount of model capability changes that arithmetic. It holds too where the artifact is the point, and the loop between hand and result is the work rather than a wrapper around it.
I am not conceding this reluctantly. Designers have been making the careful version of this case since before ChatGPT shipped, with user studies behind it.[^canon] If my test cannot survive it, it is not worth running.
The strongest argument against this section is not theirs, though. It is the Bitter Lesson: general methods that ride computation keep beating systems with human knowledge built into them, and we keep relearning it bitterly. Sutton was writing about AI research rather than product interfaces, so I am applying it by analogy, but the analogy points at my throat and not at anyone I disagree with. The usual misreading inflates that into a ban on anything purpose-built, which he never wrote. I think he is right, which is why the yes list is short and getting shorter. What survives is not the interface that encodes what its designer already knew. It is the one carrying what a sentence cannot.
Notice what a yes actually requires. It requires that the interface is doing work that no instruction can do, not that the interface is nicer, or familiar, or already built.
When the answer is no, it is a missing tool
When the test comes back no, the reason is almost never that the chat window is a better interface than the one you made. It is that the agent does not have a tool for your thing yet.
That distinction is the whole of it. Missing interfaces are product problems. Missing tools are platform problems. If the only thing standing between a person and your capability is that nobody has written the connector, you are not defending an interface. You are holding a gap in someone else's platform, and gaps get filled, usually by someone who noticed before you did. The useful move is not to defend the surface you built. It is to work out which tool was missing, and to ask whether you would rather own the tool than the surface.
Running it on myself
I have to answer the question too, and the honest version costs me something.
For a long time I have been thinking about how to make software development available to everybody. In this new era that is largely done. A person who can describe what they want can get working software out of a chat window without learning anything about how it works. That was the entire ambition, and it arrived without me.
So I asked my own question. Why not just do it in Claude?
The answer I reached is that the capability to run production software is not missing. It is borrowed. A person in a chat window can put a site on a live public URL today, but only because Vercel's server carries the deploy. Claude is not deploying anything. The database is Supabase's, the CMS is Sanity's, the payments are Stripe's.[^supabase] The borrowing pushes the difficulty onto the person least equipped to carry it: assembling the lenders first, one account and one blind choice at a time, to host it, hold its data, give the owner a way to edit their own words, tell them who visited, and take a payment. Afterward they own vendor relationships they did not choose and cannot operate. Those are not interface problems. Nobody needs a nicer dashboard for them. They are missing tools, which by my own argument makes them a platform problem, and platform problems are the ones worth building.
So I am building the platform. It is called Iconic: site hosting, database, CMS, analytics and payments in one place, reachable as tools an agent can use. The goal I keep coming back to is that it should be so easy to use that it feels more like an upgraded Squarespace than a simplified Vercel.
That is the whole pitch. The argument is the thing I care about, and the product is what happened when I took it seriously.
Your turn
So run it on your own thing. Why not just do that in Claude?
If you have an answer, it should fit in one sentence, and the sentence should not be that you already built it. Mine came back no, which was worth knowing early, and it left me holding something more useful than a better interface. It left me holding a missing tool.
[^krishna]: Golden Krishna, "The best interface is no interface," 2012. His own paradigm case is ambient inference rather than conversation, so I am borrowing the sentence and not his argument.
[^1997]: Properly staged in 1997: Ben Shneiderman and Pattie Maes, "Direct Manipulation vs. Interface Agents," Interactions 4(6), November/December 1997, 42 to 61.
[^canon]: Adi Leviim's version is the one I cannot get around: "Expressing intent does not require prose. A date picker expresses temporal intent more precisely than any sentence."
[^supabase]: Supabase's own documentation: "Remember to never connect the MCP server to production data. Supabase MCP is only designed for development and testing purposes."