Build a Small Tool in Plain English (No Code, No Kidding)

Somebody showed you a small tool they made with AI. A calculator, a tracker, a little page that actually worked. And your first thought was that they must know something you do not.

They probably do not. I want to show you what is really involved, because the distance between you and that tool is shorter than it looks, and none of it is made of code.

What the thing beside the chat is called.

When you ask Claude for something buildable, it does not answer with a description. A working object opens in its own panel next to the conversation. The name for that object is an Artifact, which is a technical-sounding word for a plain idea: a finished, usable piece of work sitting beside your chat.

An ordinary reply is words about a tool. An Artifact is the tool. Boxes you can type in, buttons you can press, a total that changes when you change a number.

Three things are true of it, and they are the whole reason this works for people who do not write software. You can see it. You can look it over and judge whether it is right. And you can use it, the way the person you built it for would use it.

There is code underneath, and you never have to open it. Treat it like the wiring behind a wall. It is what makes the light come on.

The twenty minute version.

Here is a real one, small enough to finish this afternoon. Say you are organising a family meal and you want to keep track of who is bringing what.

Open a normal conversation and send this:

Build me a small page for planning a family meal. I type in a person's name and what they are bringing, and it adds them to a list grouped into starters, mains and puddings. At the bottom, show me which of the three groups has nothing in it yet. Keep it simple and easy to read on a phone.

That is the whole request. Ordinary sentences, no special words. In under a minute the page appears next to the chat, and you can start typing names into it straight away.

Notice what that request contains, because it is the only skill here. You said what the tool is for, what goes into it, and what comes out. Everything else was polite filler. When a build comes back wrong, it is almost always because one of those three was missing.

Then you say what is wrong, in ordinary words.

The first version is a draft, not a delivery. You look at it and say what you want changed, in the same plain sentences.

Make the writing bigger. Add a fourth group for drinks. Put the missing-groups line at the top where I will see it. The same page updates in front of you. You are not starting again, you are revising one thing, and you can keep doing that until it is right.

The part most people skip.

Before you use it for anything real, ask Claude to try to break it. Ask for a short list of ways it might fail, grouped into normal use, empty fields, and silly inputs, then run through the list yourself.

Most first builds hide two or three problems. What happens if two people bring the same dish. What happens if you leave the name blank. Finding those before the family meal is the entire point, and it takes about three minutes.

Free Claude toolkit. The companion pack for my Claude book is free, and it includes more than five hundred numbered prompts you can copy and paste, including the ones for describing and testing a build. No card, and you can leave the list in one click. Get the toolkit →

You are not missing a step called learning to code.

You will hear the phrase Claude Code, and it is worth knowing what it is so it stops sounding like a door you failed to open. It is a separate, developer-focused way of building, for people working on large software projects, and it lives outside the ordinary chat window.

Think of three rungs. A plain written answer at the bottom. An Artifact in the middle. Claude Code at the top, for developers. You live comfortably on the middle rung, and almost everything a person actually wants to build lives there too: calculators, trackers, checklists, small pages.

Artifacts need nothing installed, no setting switched on and no upgrade. They work in the ordinary Claude you already open, on every plan, including the free one. There is no preparation step you skipped.

What this will not do.

It will not produce something you can hand to strangers on the first try. Yours will be good enough for you long before it is good enough for the public, and the difference is testing.

It will not remember your preferences on its own. If you build the same kind of thing often, that belongs in a Project, where your standing instructions live.

And it will not build something you cannot describe. If you do not yet know what goes in and what should come out, that thinking is the work. The typing was never the hard part.

One thing to do before the next post.

Pick the smallest thing that would be genuinely useful once. Not the ambitious version. The small one.

Describe it in three sentences: what it is for, what you type in, what it shows you. Send it, and click the thing that appears. If it does what you meant, you have built working software this afternoon, without writing a line of anything.

If you want the whole system rather than one piece of it, that is what I wrote Claude AI Bible (7 Books in 1) for. Seven books in one volume, with a fill-in-the-blank build brief, a step-by-step walkthrough in dated screenshots, and more than five hundred numbered prompts to copy.

This post is part of my Claude series. The one that started it is Why Claude Gave You a Great Answer on Monday and a Flat One on Tuesday.

Tomasz