The examples below come from work on SalarsNet and a separate listing-draft project. They are project observations, not estimates of what AI will save another business. Each one identifies the task, AI’s role, the human checkpoint, the observed result, and the limit of the evidence. Project notes were reviewed September 27, 2026; private customer and item details are omitted.
1. Newsletter page and email flow
The job: revise a Field Note page and the related subscription email flow. A reader needed to see a complete example issue before signing up, and the site needed to deliver and unsubscribe correctly.
AI’s role: Codex helped edit page copy and site code, then ran site checks. The work covered an editorial draft as well as the implementation around it. A draft generated in this way still needed a person to decide whether the promise to readers was clear and whether the email behavior matched it.
The checkpoints: The site build and automated checks could catch broken code. A delivered seed email showed what arrived in an inbox. A live unsubscribe test checked that the exit path worked. These checks ask different questions; a successful build alone cannot establish that an email was delivered or that a reader can leave the list.
Observed result and limit: The published Field Note about counting the full cost of a tool is available to read, and project records describe the delivery and unsubscribe checks. Those records do not establish a reliable manual time comparison or the amount of editorial review time. We therefore do not claim a time saving.
Reusable pattern: Let AI prepare and implement a bounded change, then inspect the actual reader experience. For a newsletter, that means the page, the received email, and the unsubscribe path—not just the draft text.
2. Photo Drafts listing assistant
The job: turn seller-provided photos and product details into an unpublished eBay listing draft. The seller still needed to inspect the title, description, condition, shipping, and other listing fields before anything went live.
AI’s role: The assistant proposed listing text and fields. The application kept the seller’s existing values where appropriate and required a deliberate “apply selected” step. The AI did not have permission to publish a listing by itself.
The checkpoints: Project verification notes record a paid live AI request, automated checks, and creation of an unpublished draft. They also record a real failure: a desktop helper could answer a ping but could not complete shipping and policy fields on the first live attempt. Those fields were then completed through the visible eBay form and the draft was saved. A later helper check succeeded on the already-completed draft; the path for filling empty policy fields was tested locally and was not rerun by clearing the live draft.
Observed result and limit: An unpublished draft was created and saved. Nothing was published. The record supports that bounded outcome, not a claim that an end-to-end automatic listing flow was proven. One model request’s reported cost would not capture seller review, helper work, corrections, or upkeep, so it is not used as a workflow cost estimate.
Reusable pattern: Separate suggestion, selection, draft saving, and publication. Test the handoff between tools, and record the first real failure rather than treating a partial success as a complete workflow.
What these examples suggest
Both projects benefited from a narrow AI role and an observable final check. The final check was different in each case: a delivered email and working unsubscribe path for the newsletter; an unpublished, inspectable draft for the listing assistant. Neither project justifies a universal time-savings number. To run your own measured version, use the 30-minute pilot worksheet, test the workflow before it acts, and count the full run from setup through review.