Prototype it with the tools you have

Build to learn, not to launch

A prototype is a rough, working version you build to learn, not to launch. Its job is to answer one question quickly: can this task be done well enough, with what you already have, to be worth a real trial?

You probably don’t need code for a first version. Three things you likely already have get you surprisingly far:

• A custom assistant: a saved assistant with your own instructions and reference files, so every chat starts from the same rules. Most of the big assistants (ChatGPT, Claude, Gemini, Copilot) offer this, each under its own name; check whether your plan includes it.
• A form (Google Forms or Microsoft Forms, for example), so the input arrives in the same shape every time, with the details the tool needs. If the tool keeps asking for the same missing detail, add that question to the form.
• A spreadsheet, to hold your test set, each version’s outputs and your pass or fail marks.

The instructions are the tool

Write the instructions from the scope and test set you already have, clearly enough that a new hire could follow them, and keep facts out of them. Your price list, policies and service area go in reference files, short and current, so there’s one place to update.

Tell the assistant to use only facts from those files. A long, messy file makes it easier to miss the one line that matters, and an out-of-date price list produces confident, wrong answers.

In plain language, the instructions cover:

• What it receives, and what to ask for if something’s missing
• The steps, in order
• The exact output format: headings, length, tone
• What it must never do: your red lines, word for word
• When to stop and write “Needs a person” instead of guessing

Test, change one thing, test again

Run your test examples one at a time, each in a fresh chat with any memory feature switched off, so earlier answers can’t leak into later ones. Use examples the instructions haven’t seen: if you pasted three into the instructions, test on the others. Paste each output into your sheet next to what good looks like, and mark it pass or fail yourself. Don’t ask the assistant to grade its own work.

When something fails, change one thing: a line in the instructions, a missing fact in a reference file, a question on the form. Save each version with a number (v1, v2) and rerun the whole test set, not just the example that failed. A fix for one case can quietly break another.

Expect the same input to get slightly different answers on different runs; that’s how these models work. Run the awkward examples twice. If the answers differ in ways that matter, the instructions aren’t specific enough yet.

Stay in the middle, and stop at good enough

In a prototype, you’re the connection between the pieces: you copy the form entry in and the draft out. That’s a feature. You see every output, and you learn where the tool is weak before anything runs on its own. Connecting the pieces with a tool like Zapier or Make can wait until the prototype has earned it; the Automator path shows how.

Stop building when the prototype clears the bar you set, and move to a pilot. Polishing a tool nobody has used on real work is an easy way to lose a month. A prototype can’t tell you whether people will use it on a busy Tuesday; that’s what the pilot is for.