From Prompt to Checkout: Describing a POS in Plain English
Five details separate a working checkout from a pretty demo: what you sell, how people pay, your tax rules, the receipt, and the exceptions. How to describe a POS the way you would train a new hire.
Describing a POS in plain English works, but only if you describe your business instead of the software. The best descriptions read like you are training a new hire on their first shift: here is what we sell, here is how people pay, here is what the receipt has to say. A prompt-based builder can turn that kind of description into a checkout you can run a real sale on. Whether you get a working register or a nice-looking demo comes down to five details, and none of them are technical.
What does a plain-English POS description sound like?
It sounds like you, on a Tuesday, showing someone the counter:
"I run a bakery with one register. We sell bread, pastries, and drip coffee. Pastries go out as singles or half dozens. Coffee comes in two sizes with milk options. Almost everyone taps a card, but we still take cash. Whole loaves are tax exempt here; everything else gets sales tax. Customers usually want their receipt emailed."
No feature names, no screens described. Seven sentences that carry the entire front of the store: the catalog, the options, the payment types, the tax rules, and the receipt. A builder can work with that. What it cannot work with is "make me a modern POS for a bakery," which describes a mood, not a business.
Which five details decide whether the checkout works?
The ones a new hire would ask about by lunch. Cover each in your own words:
What you sell and how it is grouped. Not every item, just the shape of the catalog: your categories, and whether items carry options like size or add-ons. A POS calls these options modifiers, and leaving them out is the most common reason a first build feels wrong at the register.
How people pay. Card, cash, or both, and whether tipping is part of your counter.
Your tax rules as you actually apply them. Not the legislation, your store's reality: what gets taxed, what is exempt, and whether tax is baked into the shelf price or added at the till.
What the receipt has to say. Email, print, or both, plus anything non-negotiable on it, like your business number or return policy.
The exceptions. Bottle deposits, weighed produce, staff discounts, the regular who pays at the end of the month. One sentence each is enough. A checkout that handles the normal sale but not your strange ones gets abandoned within a week, which makes the exceptions the most valuable sentences in the whole description.
What can plain English not do?
A description decides behavior; it cannot make the machinery underneath correct. Inventory that stays accurate when two sales hit the same item at once, end-of-day reports that reconcile (match the money that actually moved), tax applied the same way on the thousandth sale as on the first, and card payments that meet PCI rules (the card industry's security standard) are not things a sentence can grant. The platform your description lands on either provides them or it does not.
This is where do-it-yourself attempts stall. An AI code generator will produce convincing checkout screens from the same seven sentences, and the result looks right up until real money and real stock hit it. We have mapped where that wall sits in vibe coding a point of sale and in why a top coding model still cannot ship a working POS on its own. Plain English is a complete spec for the parts of a POS you can see. Someone still has to have built the parts you cannot.
How do you refine the first draft?
The same way you would correct that new hire: specifically, and one thing at a time. Run a test sale as soon as you have a preview, first your most common order, then your weirdest one. When something is off, fix it with a plain sentence ("half dozens should ask which six pastries") instead of re-describing the whole store. If the screen itself is what needs work, use prompt patterns that produce great POS layouts; describing the transaction rather than the screen does most of the job.
On Final, that loop is a chat: describe, preview, correct, deploy, with every change saved as a checkpoint you can roll back. The step-by-step lives in how to build your first flow, and if you would rather stay in an AI tool you already use, you can connect your own AI over MCP (a standard way to plug AI tools into other software) and build against the same live preview. There is a longer story on why prompting replaced visual builders if you are curious how we got here.
So, can plain English really get you from prompt to checkout?
Yes. A description that covers the catalog, the payment types, the tax rules, the receipt, and the exceptions is a complete spec for the front of a store, and a prompt-based builder can turn it into a checkout the same day. What no description can supply is the commerce infrastructure underneath, so point your sentences at a platform where that part already exists. The rule of thumb: describe your counter the way you would train a new hire, and let the platform handle everything a new hire never sees.
If you want to watch a description become a running register, Getting Started with Build is the five-minute version.
Frequently asked questions
Do I need technical terms to describe a POS?
No. Describe the counter the way you would train a new hire: what you sell, how people pay, your tax rules, what the receipt says, and the exceptions. The builder maps plain language to the right features.
How long should a plain English POS description be?
Five to ten sentences is enough for a first build. Cover the five core details, then refine in the live preview instead of writing a longer prompt.
What happens if I forget something in my description?
Nothing is locked in. Add it afterward with one plain corrective sentence, run the sale again, and keep going until the register behaves like your counter.
Can a plain English prompt handle taxes and card payments?
Your description sets the rules, such as what is taxed and which payment types you accept. Executing them correctly on every sale, including card processing, is the platform's job, so build on infrastructure that already handles it.
Is this the same as asking an AI code generator for a POS?
No. A code generator writes screens and logic from your description but not the payments, inventory, and reporting infrastructure a store needs. A prompt-based POS builder deploys your description onto infrastructure that already exists.