Building Artifacts & Mini-Apps

An Artifact is content Claude generates in a side panel you can see and refine - and when that content is a small web page with a bit of logic, it becomes a working tool. Think of the small instruments a practice reinvents constantly: a plaster or tile quantity calculator, a rough cost-per-square-metre estimator, an FF&E checklist that tots up a budget as you tick items, a unit converter for imperial-minded clients, a daylight-factor rule-of-thumb. Each is a genuine little app - inputs, a calculation or a checklist, an output - and each is now something you can conjure from a sentence, use immediately, and hand to a colleague.

The workflow, shown in the figure, is a short loop: you describe the tool - its inputs, its output, and the formula or rule; Claude builds it as an Artifact you can use straight away; you test it on real numbers and check the result by hand; and, when it is right, you share it. If it is not right, you tell Claude what to change and it rebuilds in place - the iterate arrow that keeps the loop honest. This is the same direct-draft-judge-refine loop from the very first lesson of the course, now producing a tool instead of a paragraph.

Be clear-eyed about what these tools are and are not. A mini-app is superb for a well-defined calculation or a structured checklist you will reuse - the repetitive, rule-based jobs, exactly as in the rest of this module. It is not a substitute for a validated engineering tool, a quantity surveyor, or a code check; it encodes your rule of thumb, no more. And its answers are only as sound as the logic inside it, which Claude wrote and you must vouch for. Used within those limits, a small verified tool is a quiet multiplier of a studio's speed and consistency.

As with formulas, the tool you get is only as good as the brief you give. Name the inputs and their units, state the output you want, give the exact formula or rule if you have one, and say how it should look and behave - one screen, no libraries, clear labels. Here is a brief for a plaster quantity calculator, the kind of thing a site architect wants on their phone:

Build an Artifact: a one-page 'plaster quantity' calculator.
Inputs: wall length (m), wall height (m), number of walls,
        coat thickness (mm), and a wastage percentage.
Output: plaster volume in cubic metres, and number of 25 kg
        bags (assume 1440 kg per cubic metre of dry mortar).
Show the formula used on screen. One screen, no libraries,
clear labels, works on a phone.

Notice the brief carries the assumptions - the bag size, the density, the bulking - because those are exactly the judgement calls you must own, not leave to Claude's default. When Claude builds it, the tool works immediately, but your job has only started. Ask to see the logic it wrote, because that is where any error hides. It might hand you something like this to read:

// The calculation Claude wrote - read it before you trust it.
const wallArea = length * height * count;          // m2
const wetVolume = wallArea * (thickness / 1000);   // m3
const dryVolume = wetVolume * 1.27;                // 27% bulking
const withWaste = dryVolume * (1 + waste / 100);
const bags = Math.ceil((withWaste * 1440) / 25);   // 25 kg bags

Read it as a sentence: area, times thickness for wet volume, times a bulking factor for dry volume, plus wastage, converted to bags and rounded up. Every assumption is visible and questionable - is 1.27 the bulking factor your practice uses? Is 1440 the right density for your mortar? Those are your calls to confirm against your own standard, and the whole point of showing the logic is that you can.

The magic of an Artifact is that refining it is a conversation, not a rebuild from scratch. You use the tool, notice what is wrong or missing, and say so in plain English - and Claude edits the tool in the panel while you watch. "The bulking factor should be 1.3, not 1.27." "Add a field for door and window openings to subtract from the wall area." "Show the cost too, at a rate I can type in." "Round bags up and show the leftover." Each request reshapes the tool in place. This is the iterate arrow in the figure, and it is where a rough first build becomes something genuinely fitted to how you work.

Iterate in small, testable steps rather than one giant wish-list, for the same reason you check one spreadsheet cell before filling down: after each change, test the tool again on a case whose answer you know, so you always know which change introduced a problem. If you ask for six changes at once and the number goes wrong, you have to untangle which one did it; ask for one, verify, ask for the next, and every step stays checkable. Keep the on-screen formula visible as you go, so the tool always shows its working and you - or a colleague - can see what it is doing rather than trusting a black box.

The anatomy in the figure is worth holding in mind while you iterate: every mini-app is inputs, logic, and output, and the logic is the box where errors live. Cosmetic changes - labels, layout, a title - are low-stakes; you can accept them on sight. Logic changes - a factor, a formula, a rounding rule, a new calculation - are the ones to test every single time, because they change the answers. Train yourself to feel that difference: relax on the appearance, tighten on the maths. That is scrutiny scaled to the stakes, the discipline from lesson one, applied to a tool you are building.

Before a mini-app leaves your hands, verify it the way you would sign off any output that carries your name. Run it on two or three cases whose answers you have worked out by hand, including an easy round-number case and a realistic messy one. Push the edges: what happens with a zero, a blank field, an absurdly large number? A good tool handles these gracefully; a fragile one gives nonsense, and better you find that than a colleague on site. Confirm the on-screen formula matches the logic you read, and that every assumption - factors, densities, rates - is the one your practice actually uses. Only when it survives all that is it ready to trust.

Sharing is what turns a personal calculation into studio infrastructure, and Artifacts can be shared so others open and use the tool. This is a real gift and a real responsibility. The gift is consistency: everyone uses the same plaster factor, the same checklist, the same cost basis, and the studio stops reinventing the wheel. The responsibility is that a shared tool spreads its answers - and its errors - to everyone, silently, long after you built it. So share only what you have verified, put the assumptions and a 'last checked' date on the tool itself, and treat a change to shared logic as something to re-verify, not a casual edit. A note on the tool saying which factors it uses lets the next person judge whether it fits their case.

That is the whole of Module 8 in miniature, and the whole spine of the course. Claude wrote code, formulas and now working tools from your plain-English intent, collapsing work that used to need a programmer into a conversation. At every step the same three acts stayed yours: read what it built, run it on a copy or real case, and verify the result against something you know - with your scrutiny scaled to the stakes, loosest on a label and tightest on a shared calculation. Claude builds the instrument; you are the one who vouches for it. Take that habit into your practice and you gain enormous leverage without ever surrendering the judgement, or the accountability, that make you the designer of record.

And notice how far you have travelled. At the start of this module, code was a closed door; now you can direct Claude to write Python, script a BIM model, build a spreadsheet and construct a working tool - none of it by learning to program, all of it by describing intent and checking results. That is a genuine expansion of what one designer can do in a day. Guard it with the one discipline that made it safe, and it will serve you for the rest of your career.