Proof of concept: software examples, a template, and PoC vs MVP

What is a proof of concept?

A proof of concept reduces a specific uncertainty. For a software founder, that might be whether a provider exposes the records your workflow needs, whether an importer can reject malformed input clearly, or whether an extraction approach works on the document types customers actually use. The useful output is a decision supported by inspectable evidence, not necessarily an attractive interface.

The scope varies by organization. AWS’s guidance for generative AI PoCs considers business value, data readiness, technical feasibility, and delivery risk together. A small SaaS experiment can be much narrower, provided its scope is explicit. Write down which question this run answers and which questions remain open before you start building.

For an original fictional example, BriefBoard is a proposed tool for collecting design-project briefs. Its founder is uncertain whether incoming structured records can be normalized without silently accepting missing project names or invalid budgets. That contract question can be tested locally before building account management, billing, or a polished dashboard.

• AWS: defining the questions and evidence for a generative AI proof of concept

Proof of concept vs prototype vs MVP

A common working distinction is feasibility, interaction, and real use. A PoC investigates whether an approach can work under specified conditions. A prototype helps people inspect or try a proposed experience. An MVP delivers a small but usable outcome to real users so the team can learn about demand and operation. Teams use these labels differently, so explain the actual deliverable alongside the name.

You do not need all three artifacts in a fixed sequence. If a standard form and database already solve the technical problem, another feasibility demo may add little. If the uncertainty is whether customers care enough to change their workflow, a technical success will not answer it. Use the idea-validation guide for that question.

Write a PoC plan before writing the implementation

Start with the decision that the experiment will inform. For BriefBoard, the decision is whether to continue with a structured import boundary or redesign the contract. Name an owner, time limit, permitted test data, and a budget limit if a paid service is involved. These are constraints for this experiment, not generic targets every founder should copy.

Define pass and fail conditions in advance. Our local exercise accepts a nonempty project name, a finite nonnegative budget within its stated bound, and up to five file-name strings. It must reject malformed records with a reason. This is intentionally a toy contract: file names are metadata, and no file contents are opened, uploaded, or scanned.

List representative cases, including failures you would prefer not to discover after launch. A real import investigation might also need permissions, provider pagination, rate limits, inaccessible records, schema changes, encoding, large payloads, and recovery after partial progress. The download separates those untested items from the small local contract exercise.

Question: can this local contract distinguish the six supplied valid/invalid records?
Evidence: named fixture inputs, normalized output, and rejection reasons.
Pass rule: all six outcomes match expectations; invalid records produce no normalized brief.
Time boundary: one local exercise, then review the missing real-world cases.
Next decision: continue the contract design, change it, or investigate a representative provider fixture.
Not established: API access, throughput, security review, production reliability, or paid demand.

Run the original local proof-of-concept example

Download the JavaScript lab at the end of this guide and run node proof-of-concept-lab.mjs with Node.js 22 or newer. It uses only synthetic values bundled in the file. It makes no network calls, reads no customer files, requests no credentials, and writes no files. Its output is printed to your terminal.

The unchanged fixture set contains three valid inputs and three invalid inputs. The valid cases cover a plain project, a Unicode name with surrounding whitespace, and a zero budget with no files. The invalid cases cover a missing project, a negative budget, and a file field with the wrong type. The expected output is total 6, accepted 3, rejected 3, and matchedExpectations 6.

Inspect the normalized record and rejection reason for each case instead of reading only the summary. Add a new fixture before changing the validator. If you change a requirement, update the expected result deliberately and explain why. The function is exported so you can call it from your own local tests without starting a server.

Choose the next test from the risk you still have

Six matching synthetic cases establish only that this implementation behaves as expected for those cases. They do not measure performance or show that an external integration supplies the same shape. A useful next step is to obtain a permitted representative fixture from the actual boundary and test it against a versioned contract.

For an external API PoC, record the requested scope, the documented response shape, and how the experiment behaves when access is denied or a record changes. For an AI extraction PoC, define correctness using representative inputs and a reviewed answer set; a plausible-looking answer is not a correctness measure. Keep cost and latency measurements tied to the actual run conditions.

AWS’s proof-of-technology discussion illustrates the value of evaluating a configuration against explicit requirements. Apply that discipline to your own narrow question. Do not relabel a failed requirement as success because a different part of the demo looked convincing.

• AWS: evaluating whether a configuration meets defined requirements

Decide what happens to the result and the code

End with a short evidence record: conditions, fixture version, outcomes, failures, unresolved questions, and a decision owner. Continuing can mean running one more focused experiment. Stopping can be the right result when access, quality, or costs make the proposed workflow unsuitable.

If the code becomes part of a product, give it a separate production review. Authentication, authorization, monitoring, input limits, dependency handling, data retention, and recovery need their own decisions. A passing fixture suite is useful evidence, but it does not turn experiment code into a complete service.

Once feasibility is sufficiently understood, the micro-SaaS MVP guide helps narrow a usable first workflow. Keep the original PoC decision record so later changes can be compared with what you actually learned rather than a memory of a successful demonstration.

Download the PoC plan and runnable lab

The original plan includes the completed BriefBoard experiment card, a fixture checklist, and blank fields for your next feasibility question. The lab makes the six local outcomes reproducible. All cases are synthetic teaching data; sources were checked on October 27, 2026.

• Download the proof-of-concept plan (TXT)
• Download the local PoC lab (JavaScript)