--- title: "Line-by-Line Custom Order Confirmation" date: "2026-08-03" canonical: "https://raytally.com/en/ideas/2026-08-03-idea-567dc74e/" generator: "RayTally · dev-prompt-v4" signal: query: "How do you protect yourself from \"I never approved that\" disputes on custom orders?" observed_at: "2026-08-03T00:33:14.347Z" sources: - url: "https://www.reddit.com/r/smallbusiness/comments/1vdvass/how_do_you_protect_yourself_from_i_never_approved/" boundary: "Published at 2026-08-02T22:16:36.000Z. Observed at 2026-08-03T00:33:14.347Z." - url: "https://developers.cloudflare.com/r2/api/s3/presigned-urls/" boundary: "Published at 2026-04-24T00:00:00.000Z." - url: "https://docs.stripe.com/payment-links/customize?dashboard-or-api=api" boundary: "No publication timestamp is present in the source record." - url: "https://proofapprove.com/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-03-idea-567dc74e/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Line-by-Line Custom Order Confirmation Before a custom order enters production, customers review and confirm each dimension, text element, and reference image, creating a versioned record both sides can revisit. ## Product concept Merchants selling custom goods dread the moment when a customer says “make it like this” in chat, then claims after delivery that the size, color, or wording was not what they wanted. Screenshots can miss a version, and production staff may combine an old reference image with new requirements on the same work order. When a merchant is ready to collect payment or begin production, they place the dimensions, color, material, engraving text, and reference images on one confirmation page. The system separates the fields most likely to cause disputes, and customers must open each one before they can confirm. Text appears in an actual layout preview, while images are fixed to the current order with their version numbers. Once confirmation is complete, both parties receive a read-only snapshot containing the specifications, images, confirmation time, and version number they saw. If the customer later requests a change, the merchant creates a new version from the old one. The page highlights only what changed and requires confirmation again. Production staff can see only the current valid version when they open the work order. The first version supports common custom fields such as dimensions, color, text, and materials, solving the confirmation loop before production begins. It does not decide aesthetic disputes or replace a contract; it ensures both sides see and confirm the same concrete description of the finished item before it is made. ## Why now (backed by facts) On August 2, a small-business owner posted that a customer denied approving specific details after a custom order had shipped. The post connects scattered chats, mixed-up versions, and later denial into a single dispute chain—exactly the confirmation gap merchants face before collecting payment or starting production. ## Direction (model inference, not independently verified) Target user: Merchants selling personalized goods through WeChat, SMS, email, or marketplace direct messages. It matters most after the quote is set and just before payment collection or production scheduling, when reference images may have changed several times and sales and production staff may be handing off the order. Order volume need not be high: if a single remake can erase the profit, a recorded confirmation has clear value. Minimal entry point: First, model each order as four record types: fields, attachments, versions, and confirmation events. Upload images directly through R2 presigned URLs, while the server stores the object key, hash, and version number. Customers can confirm only after expanding each field. Text is previewed using the merchant’s selected font, size, and layout frame. At confirmation, freeze normalized JSON and attachment hashes, then generate a read-only web page and PDF. Create changes as a new version derived from the old one, comparing only field values and attachment hashes. The production view reads only the current valid version. For merchants using Stripe, create a payment link after confirmation. Its custom fields, terms acceptance, and completion webhook can connect the confirmation to payment. The strongest case against: Requiring customers to open each field adds friction, and too many fields can encourage careless confirmation. If previews do not accurately represent the font, color variation, cropping, or material texture, the snapshot may create false certainty instead. A forwarded link also makes it difficult to prove who the actual decision-maker was. If a team can still start production from chat attachments, the version gate fails. An evidence package can reduce the work of gathering materials, but cannot ensure that a platform, payment provider, or court will accept it. Merchants must also bear the operational costs of attachment privacy, retention periods, exports, and deletion requests. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Reach the first users through Etsy, Shopify, laser engraving, and embroidery merchant communities. Exchange an anonymized rework-dispute review template for real order workflows, then configure the first confirmation template for participating merchants. Demos should focus on change differences and production work orders, not on promises of legal wins. A Shopify order-page plugin could also embed the confirmation link into merchants’ existing fulfillment workflow. ## Competitors & gaps (model inference) - Proof Approve: Proof Approve already supports PDF, PNG, and JPG uploads and can send private review links that do not require an account. Customers can approve or reject, leaving a name signature, timestamp, and comments. Each revision and decision is recorded in the order activity history. These features already address version ownership and scattered feedback in design-proof approvals. Its public materials still focus on the proof as a whole; they do not appear to require customers to open individual fields such as dimensions, materials, and engraving. Nor do they show a typeset engraving preview or a freeze of field values, image versions, and attachment hashes together. This product should turn field-level confirmation into a production gate and highlight only actual changes in a new version. If the job is simply approving one design proof, Proof Approve is easier; if the artwork is only one part of a complex specification, this product is a better fit. ## How it makes money (model inference) Charge a monthly fee per merchant workspace, with tiers based on confirmed-order volume. Every tier includes snapshot exports; higher tiers add team seats, branded domains, and longer attachment retention. Do not charge based on dispute outcomes, so merchants do not mistake the service for a promise of winning a case or receiving compensation. ## Source context Theme: Customer confirmation and evidence trail for key custom-order specifications Trigger Web Trend observation: u/Ok_computer9956（r/smallbusiness） — How do you protect yourself from "I never approved that" disputes on custom orders? This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - How do you protect yourself from "I never approved that" disputes on custom orders? (https://www.reddit.com/r/smallbusiness/comments/1vdvass/how_do_you_protect_yourself_from_i_never_approved/) - Presigned URLs · Cloudflare R2 docs (https://developers.cloudflare.com/r2/api/s3/presigned-urls/) - Customize checkout for Payment Links (https://docs.stripe.com/payment-links/customize?dashboard-or-api=api) - Proof Approve | Signed Proof Approval Software for Custom Shops (https://proofapprove.com/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.