Is My Idea Just a Prompt, a Skill, a Clone, or a System?

Here's the one-line test. What's the smallest thing someone would have to reproduce to replace you, and can they just type it? That question sorts any software idea onto one of four rungs, and asking "is my idea just a prompt" before the build instead of three weeks into it is the difference between a cheap lesson and an expensive one. The rungs run from a prompt at the bottom to a system at the top, and somewhere in the middle is the line that decides whether you have an AI wrapper or a real product. I call it the Moat Line. Below it, the thing that makes you valuable can be typed into existence. Above it, it can't.

A prompt

A prompt is when the whole product is one model call and the model already does the job, so the honest pitch is "I put a text box around something you already have."

You're here if your app is a summarizer, a rewriter, an extract-my-action-items tool, anything where the work happens inside a single request and you're mostly choosing the wording. The tell is the API key one: if losing your API key would kill the company, you didn't build a product, you wrote a fancy prompt. Jasper is the example everyone reaches for, a billion-dollar wrapper around text generation right up until GPT-4 shipped the same core feature for nothing and the floor went out from under it. To climb you add the one thing the model can't do alone.

A skill

A skill is a prompt with packaging around it, a few instructions, a reference file or two, maybe a tool wired in, the kind of thing you ship as a Claude Skill or a custom GPT.

You're here if there's a config involved and the config is the product. It feels sturdier than a prompt because you assembled something, but a competent user rebuilds it in an afternoon once they've seen what it does. This rung barely existed eighteen months ago, which is why so many people stand on it convinced they've built something heavier than they have. To climb, the packaging has to do something a copy of it can't, and a config file copies perfectly.

A weekend clone

A weekend clone is a real product, a codebase, a database, an interface, the kind of thing that used to take a small team a quarter and now takes a good builder a weekend with Cursor or Claude Code.

You're here if you shipped something that works and feels substantial, which is exactly where the trap is. Pieter Levels built a browser flight simulator in roughly three hours with no game-development background and had north of three hundred thousand players inside a couple of weeks. Impressive, and also the whole point: the weekend buys you the demo, not the company, and the distance between those two is most of the work. If a weekend reproduces your demo, the code was never your moat, and "mine handles the edge cases" won't save you, because the next person's Claude Code handles them too. The climb here is the steepest, from a thing that works to a thing that's hard to leave.

A system

A system is what sits above the Moat Line. To replace you here, someone has to rebuild what took years to pile up and can't be typed: a data flywheel that compounds every time a customer uses you, a network you assemble one user at a time, lock-in nobody rips out without rewiring half their stack, trust you earn slowly where being wrong is expensive.

You're here if a competitor with more money than you, who copied your software in full, still couldn't catch you, because the thing they'd need isn't in the code. The Samwer brothers cloned Airbnb's software in a few weeks and shipped it across Europe as Wimdu, funded north of ninety million dollars, and it should have worked on every spreadsheet. What they couldn't clone was the hosts and guests already on Airbnb, and that one fact ate the whole effort. Here's the correction I had to make in my own head, the most useful thing on this page: hard-to-build is not the same as rung four. Difficulty buys a lead, not a moat, and a16z put it in a line I keep coming back to, that differentiation is not the same as defensibility. The hard thing becomes a system only when it throws off data or lock-in or scale the next builder can't catch. Until then it's a head start with a stopwatch running.

The four rungs, side by side

Rung	What it is	Who can reproduce it	The tell	The climb
Prompt	One model call; the model already does the job	Anyone with the API	Losing your API key kills the company	Add what the model can't do alone
Skill	A prompt plus packaging, instructions, a reference file, a tool	A competent user, in an afternoon	The config is the whole product	Make the packaging do something a copy can't
Weekend clone	A real codebase, database, interface	A good builder, in a weekend with Cursor or Claude Code	A weekend rebuilds your demo	Turn the working thing into a hard-to-leave thing
System	Years of data, network, lock-in, trust	Nobody quickly, even with more money	A funded clone copies the software and still can't catch you	You're already climbing; keep the flywheel turning

So run the test on your own idea, and if the answer is yes today, that's not a death sentence. Almost everything starts below the line, and the studio I run has charged for plenty of things that were one good idea above a text box. The mistake isn't starting as a wrapper, it's staying one until the platform ships your feature at its next demo day. The better question is what would make the answer no in a year, and whether you're the person who'll get it there.

I built a small thing that runs this test for you at shoulditbeaprompt.com. You describe the idea, it names the rung, and it proves the verdict by handing you the prompt or the skill that would replace you. Better to find out now than three weeks into the build.

Common questions

Is every AI wrapper a bad business?

No. A wrapper can be a good business and a terrible moat at once, and those are two different questions. Plenty of below-the-line products make money for a while, especially for someone who owns the audience with the problem and will out-build any cloner out of plain obsession. The danger isn't being a wrapper today, it's planning to still be one when the platform ships your feature for free. It has to be a wedge into something harder, not the whole plan.

Is hard-to-build the same as defensible?

No, and it's the most expensive confusion on the ladder. Hard tech buys you a lead, not a moat, because difficulty is what the tools are collapsing fastest, and a thing that took you six months can take the next builder a fraction of that. Complexity turns into defensibility only when it compounds into one of the durable kinds, data or network or lock-in or trust. Until the hard thing throws off an advantage that grows on its own, it's a stopwatch running, not a wall.

How do I know which rung I'm on?

Ask what the smallest replaceable version of you is, then who could build it and how fast. If a model already does the job, you're a prompt. If the job needs packaging a competent user could copy in an afternoon, you're a skill. If it needs a real codebase a good builder could rebuild in a weekend, you're a clone, and if replacing you means rebuilding years of data, network, or trust that nobody can type, you're a system. Most people guess one rung too high, so when you're unsure, assume you're lower.