PROOF-OF-CONCEPT PLAN — ORIGINAL SHOWMEYOURSAAS WORKSHEET
Date: 2026-10-27
Guide: https://showmeyoursaas.com/articles/proof-of-concept/

Purpose: make one uncertainty and the next decision explicit. The completed
example below is fictional; the local lab uses synthetic fixtures only.

COMPLETED EXAMPLE: BRIEFBOARD INPUT CONTRACT
Decision: continue this structured import boundary, revise it, or investigate
one representative external fixture before building a larger workflow.
Question: can our local contract distinguish the six supplied valid/invalid
records without producing a normalized brief for an invalid record?
Input contract:
- One object with a project string of 1–120 trimmed characters.
- Numeric finite budget from 0 through 1,000,000.
- Up to five file-name strings, each nonempty and at most 200 characters.
- File names are metadata only; no file contents are read or inspected.
Pass rule: all six expected outcomes match; rejected records include a reason.
Bound: one local exercise, followed by a review of missing real-world cases.

REPRODUCE THE EXAMPLE
1. Download proof-of-concept-lab.mjs from the guide.
2. With Node.js 22 or newer: node proof-of-concept-lab.mjs
3. Inspect each fixture, not just the summary.
Expected: total=6, accepted=3, rejected=3, matchedExpectations=6.
Accepted: plain input; Unicode name with whitespace trimmed; zero budget.
Rejected: missing project; negative budget; wrong file-field type.
The lab makes no network calls, requests no credentials, and writes no files.

WHAT THIS DOES NOT ESTABLISH
Actual provider access, pagination, large input behavior, concurrency, latency,
throughput, rate limits, permissions, security review, production recovery,
business demand, willingness to pay, or economic sustainability.
Six matching fixtures are evidence only about those tested cases.

YOUR NEXT POC
Owner and review date:
Decision this evidence will inform:
One uncertainty:
Permitted input source and representative cases:
Expected valid outputs:
Invalid, denied, delayed, or partially completed cases:
Success criterion chosen before the run:
Failure criterion chosen before the run:
Time limit and spending limit, if applicable:
Provider/version/configuration, if applicable:
Measured result and raw evidence location:
Observed facts:
Interpretations and remaining uncertainty:
Decision: stop / revise / continue / investigate one next boundary
Next owner and date:

IF EXPERIMENT CODE CONTINUES INTO A PRODUCT
Review authentication, authorization, monitoring, limits, data handling,
maintenance, dependency behavior, and recovery separately. Keep the original
experiment record so a later change does not erase the evidence boundary.

Sources for concepts, checked 2026-10-27:
https://docs.aws.amazon.com/prescriptive-guidance/latest/gen-ai-lifecycle-operational-excellence/dev-architecting.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-evaluating-security-service/service-evaluation.html
All fixture names, scenarios, and worksheet wording here are original.