A real two-store shop does it on its live system. Ozark Cleaners, a wet cleaner in Arkadelphia and Hot Springs, Arkansas, runs on point-of-sale software built with Claude, the AI made by Anthropic. When the owner, Brayden, hits something at the counter, he says what he wants in plain words. Claude Code changes the code, writes a test named after his request, and the change goes live only if every test passes.
94 commits to the live system since Oct 1, on 9 of the 12 days — 13 on Oct 12 alone. As of Oct 12, 2026.
after clocking in or out the screen should return home, not back to the hub
The pipeline
This is the real sequence the shop's Claude sessions follow, written down in its repositories. Each step is a rule, a file or a script you could point to.
The owner types into the Claude session on the computer in front of him: the plant PC during the shop day, his home PC in the evening. His words are copied into the desk log, the commit message and the test's heading, typos and all.
Every one of the live system's 3,973 functions carries a keyword label from one shared list, so a search returns the function, its file and line, and a one-line purpose. Past work is found the same way, by searching the desks' logs.
The change goes into the existing functions on the live system's branch. Customer and money records are never changed by editing code; those go through the app's own functions, on its activity log.
A new numbered section goes at the end of the test file, and its heading quotes the request, like §695 — A DRAWER ALERT IS $1 OR MORE, from the owner's "i don't want to get cash drawer alerts for any amount less than $1". Every proof needs a negative control: a check that shows it would catch the old behavior. Since the switch, 91 proof sections have been added (§616 to §706), and 43 of the 50 headings that group them quote the owner.
The whole suite takes about 10 minutes and must end "0 failed"; on Oct 12 that was 1,226 passed. It also fails if the code's search index is out of date. The commit carries the request, the proof number and a Claude co-author line. Helper agents in a multi-agent run never push or deploy.
The deploy script refuses unless the change is committed and pushed. It runs the whole suite again on the server, in the live system's time zone, and refuses on any failure with nothing changed. Then it puts the build live; if the new build doesn't answer as itself within 30 seconds, the previous one goes back live by itself. The 5 newest previous builds are kept for a one-line rollback, and a last check confirms the public address is serving this exact build.
The rule is that new builds go live after the shop day, and when the counter needs a fix right away, the owner says so. It is a rule the sessions follow, not something the script enforces, and many fixes since the switch have gone live during the day.
A new entry goes at the top of that desk's log: what the owner asked, what changed, which build is live, what was checked, and what is still waiting on him. It is committed, so the next session at any desk can find it.
Four desks: the owner's PC, the plant, the Hot Springs counter and the Arkadelphia counter. Each keeps a short file of facts about that machine, a log with the newest entry first, and a to-do folder. Finished to-dos are moved to a done folder, never deleted. All four have logged since the switch.
One day, start to finish
13 commits between 9:14 AM and 9:05 PM, most of them answers to something the owner ran into or asked for that day. 5 builds were named live in the desk logs.
A build named live in the desk logs. Each one carries every commit before it.
| Day | Commits |
|---|---|
| Oct 1 | 36 |
| Oct 2 | 2 |
| Oct 3 | 0 |
| Oct 4 | 1 |
| Oct 5 | 13 |
| Oct 6 | 10 |
| Oct 7 | 5 |
| Oct 8 | 10 |
| Oct 9 | 4 |
| Oct 10 | 0 |
| Oct 11 | 0 |
| Oct 12 | 13 |
From the shop floor
Real requests, in the owner's own words, newest first. Where a customer's name or a tag number was in the request, it is shown in brackets.
detail just let me scan [a tag] onto the order twice
What changed. A garment tag already on another piece of the same ticket is now refused at the tag box, which opens the piece that has it, and a ticket wearing one tag twice can't be saved. A check of the shop's data found no saved ticket carrying a tag twice, so any duplicate could only have been in an unsaved draft.
Live that night
all orders quicked as a happy bag are supposed to add the happy bag to the first order's piece count... it seems like it is putting a happy bag on every order
What changed. The $0 Happy Bag piece now goes on once per physical bag, and only on orders rung in as a Happy Bag. The first version was written, then held back before it ever went live, because the records showed one "customer" was really a person and his company account. Claude asked the owner how bags are shared and re-did it by bag number.
Live that night
i just froze the reader up trying to run [a customer]... it said 'free the reader'
What changed. The money was checked first: the customer had been charged once, and a stray read was approved and then voided by a guard already in place. The cause was leaving the pickup screen while the card reader was waiting. Now leaving the screen any way stops the waiting read at the terminal and logs it.
Live that day
i don't want to get cash drawer alerts for any amount less than $1
What changed. The drawer alerts for the morning count and the evening over/short now fire only at $1.00 or more, and the cents are still kept on the drawer and the slip. Two other places, the morning count's on-screen flag and the theft watch, Claude did not change on its own; it asked. When the owner said "apply the $1 rule too", those followed at 9:05 PM: under a dollar is still shown to the cent but not flagged, and the theft watch still sums every cent.
Live that day, and the rest that night
there should be no way to get out of a detail screen that information has been put into without it saving
What changed. Leaving the Detail screen any way (a tab, Home, Back, another ticket, the next clerk's PIN) now saves what was typed. First, Claude checked every Detail visit since Oct 1: 115 ended without a save. Nearly all were finished minutes later by the same person; one was truly lost.
Live that morning
move the price up for sweater, comforter, and down comforter.. make the down $45, not 50
What changed. After Claude compared the prices Arkansas cleaners publish, and found the shop below a Little Rock cleaner on sweaters and comforters, he raised three: Sweater $6.75 to $7.25, Comforter $32 to $35, Down Comforter $36.75 to $45. They were set through the app's own price book from a temporary Claude station, with the owner as the deciding person, then read back. Pieces already detailed keep their price.
No code changed, so no proof: it was read back instead
after clocking in or out the screen should return home, not back to the hub
What changed. After clocking in or out, the tablet goes to the Home screen instead of back to whatever screen was under the clock. Cancel stays put. It is the request in the conversation at the top of this page.
Live that evening
our site needs a FAQ's page... · make sure our meta data is good and we are being found · i say yes, get all this right for me
What changed. Not only the POS: the shop's public website got a FAQ page with 14 answers (turnaround, Rush, pickup limits) drawn from the site's own facts and the owner's words, new page titles and descriptions, structured data for both stores, and a sitemap. Old backup copies, one still promising free pickup across five towns, were moved out of the public folder. The site was backed up first, and the answers were fact-checked by a 6-agent run.
Live that evening, on his yes
i can't even ring in a wash and fold... we had a great process in v1 where i scanned the quick and just filled in the weight... i need to ring an order in
What changed. A Wash & Fold quick ticket opens straight on its bag with the cursor in the weight box, the way the old system did. This repaired a dead end that a change made the day before had created.
Live that afternoon
the law is that wherever they pick it up is what the tax is charged... an alert should popup if an arkadelphia customer goes into hot springs, and ask which store they will pickup at
What changed. When a customer from the other store is rung in, the screen asks "which store will they pick it up at?" The answer sets the order's store, its tax rate, and where its tickets send the clothes after assembly. Moving a finished order to the other store re-taxes it, unless money is already on it.
Live that night
when we run a pickup on an order with a card on file, i need the card on file button to be bigger, like it's the main option to use... the other's are there still as backups
What changed. With a card on file, "charge the card on file" is a big full-width button at the top of the pickup, with Cash, Check, Card and Split below as backups. It uses the same single charge path: confirm, charged once.
Live that day
we got a double rush charge on [a customer], please fix it and make sure there are no more and it can't happen again
What changed. A percentage charge like Rush is now charged once: every Detail save keeps one, and the server refuses an order carrying it twice. Open tickets were re-priced. Refunds for orders already paid were left as the owner's decision, with the exact amounts listed for him.
Live that afternoon
The record
Every figure below was counted from the shop's git history, its desk logs or its test file. They grow most days, so each one is dated.
As of Oct 12, 2026
commits to the live system's code since Oct 1
96 counting from the switch itself, the night of Sept 30. 93 without the one merge.
days from Oct 1 to Oct 12 on which the live system's code changed
The quiet days were Oct 3, 10 and 11. Counting the desks' log entries too, something was committed on 11 of the 12.
builds put live since the switch
Named live in the desk logs, Oct 1–12, on 9 different days. A floor: a few late builds are logged only as "deploying".
proofs in the test suite: 1,226 passed, 0 failed on Oct 12
26 at this system's first commit on Sept 16, 1,079 in the build that went live the morning of Oct 1, and 147 more since.
changes since Oct 1 that quote the owner's own words in the commit message
Each message was checked by eye. 19 name him right in the title, like "(owner 10/12)", and 5 quote him there.
deploys the server refused because the full test run failed
Since the switch. Each time, the shop kept the build it was already running.
commits in the whole history that carry a "Co-Authored-By: Claude" line
From June 20 to Oct 12, 2026, on 89 different days. All 93 changes since Oct 1 carry it.
functions with a keyword label, so Claude can search the code instead of reading it
Across 284 files. The app itself, not counting tools and tests, is about 41,000 lines.
Guardrails
The rules below are written into the shop's repositories, and every Claude session starts from them. Several are also enforced by the software itself.
“The live shop wins, always.”
The prime directive of the safety charter the owner asked for on Sept 12, 2026 ("build the claude intro that keeps the AI safe working on a live production environment"). It also says a plain-English request is a spec, not a merge to live.
No refund, void or re-charge from a guess: the card log, the processor's funding and the POS records are checked first. On the shop's server, refunds, voids, write-offs and account credits are owner-only, and store credit, clock edits and staff changes need a PIN the server checks. Claude can't hold or type a PIN.
When the owner asked Claude to credit back repeat fees, Claude built it so its desk can only suggest each credit; he approves each one with his own PIN, and a proof shows a desk that tries to give credit itself is refused.
"A test that cannot fail is not evidence." Every new proof carries a negative control showing it would catch the old behavior. The phrase "negative control" appears on 914 lines of the 26,333-line proof file.
Deploys go only through the deploy script. It refuses a stale, uncommitted or failing build, keeps the previous builds, and puts the last one back by itself if the new one doesn't answer. At least 6 deploys have been refused since the switch; the shop kept its running build each time.
Unless the owner says go. To be plain about it: this is a discipline, not a lock. Many fixes have gone live during the day while the counter waited on them, and the logs record his go for some, not every one. One went live by accident: on Oct 7 a build went live at 4:26 PM because of a time-zone trap.
Customer and money data change only through the app's own functions, so every change lands on its activity log. Each fix is a script with a savepoint, a dry run, the change and a read-back. Claude's changes are recorded as Claude's desk, a temporary station revoked afterward, because the owner asked for exactly that: "you should be using your own access that says claude did it, not brayden".
In the live system every change is a fact recorded once, never edited or erased. A record is retired, never hard-deleted, and a mistake is fixed by adding a new fact.
Customers who share a phone are never merged. On Oct 12 a merge the owner had approved, based on a wrong description, was stopped when the dry run showed a person and his company account. Nothing was merged.
Keys live only on the server and are never printed, pasted, committed or typed. Card numbers never reach the POS; it holds the processor's tokens only.
Texts or e-mails Claude would send to customers, public web pages, DNS, scheduled tasks and lasting settings need the owner's explicit yes first. DNS changes are add-only.
The shop's first system is frozen and locked, so it can't charge, text or e-mail, but it still runs for looking up history, and the steps to flip back are written down.
Honest limits
If you're deciding whether to work this way, these matter as much as the numbers.
Your turn
customPOS gives you the starting point: a point of sale you download and own, in a form Claude Code can read and change.
Build one for your trade in the builder: you download one HTML file and a CLAUDE.md guide written for it. Or download the Single-PC Edition, the shop's first system as one file.
Claude Code is Anthropic's coding tool. Put your POS file and its guide in a folder and open that folder in Claude Code on your own computer.
Ask Claude to show you what it changed and to test it, and keep a backup before you use the new version.
"Make the card-on-file button the big one at pickup."What you get today, honestly: your POS is a single file, plus its CLAUDE.md guide. It doesn't come with the shop's 1,226-proof suite, its server checks or its automatic rollback; those belong to the shop's own multi-station system, which isn't in customPOS yet. So start small, keep backups, and try each change before your counter depends on it.
Claude is made by Anthropic. customPOS is independent and not affiliated with Anthropic.
Yes. Ozark Cleaners, a two-store wet cleaner in Arkadelphia and Hot Springs, Arkansas, has run on its own software since summer 2026; the first commit was on June 20. It moved to its current multi-computer system on September 30, and that system's code changed on 9 of the 12 days that followed.
No. Staff run the counter. Claude changes code and data only when someone asks, and a person decides anything that involves money, customers or the public.
No. Refunds, voids and credits are the owner's. On the shop's server those actions are owner-only, privileged ones need a PIN that the server checks, and Claude cannot hold or type a PIN. Claude can suggest a store credit; the owner approves it with his own PIN.
Most problems are caught before they go live: every change gets a proof, the whole suite runs on the shop's computer and again on the server, and the deploy is refused on any failure. If a new build does not answer within 30 seconds, the previous build goes back live by itself. Some mistakes still get through and are found at the counter; the fix then takes the same path.
The shop's owner describes what he wants in plain words, and Claude Code writes the code and the tests. You do need to say clearly what you want, check the result before you rely on it, and keep backups.
Not all of it. The shop's own repositories are private. customPOS publishes scrubbed exports with no customer or staff data: the Single-PC Edition is the shop's first system as one file. The multi-station system the shop runs today is not in customPOS yet.
customPOS is free. Claude is not: AI usage is paid to Anthropic under its own pricing. The shop keeps the cost down by having each desk's Claude work alone by default and saving large multi-agent runs for build work, with the cost stated first.
No. Claude is made by Anthropic. customPOS is independent and not affiliated with Anthropic.
Build it in a few minutes, download it, and change it by saying what you want.