Proof of Concept (PoC).

Prototype, proof of concept and MVP are often used interchangeably, but they answer different questions. The prototype asks: do users understand the workflow? The MVP asks: do they keep using it voluntarily? The PoC asks one thing only: is this technically possible, in this environment, with this data? Design, usability and code cleanliness are therefore irrelevant to it. A command-line script that runs the critical step once is entirely sufficient. Make a PoC pretty and it stops being a PoC; it becomes the expensive start of an implementation nobody has decided on.

A usable PoC has three things written down before the first line of code: the assumption to be tested in one sentence, the abort criterion, and a hard time budget. A few days to two weeks is typical. The abort criterion is the most important part, because experience shows that a PoC without a defined failure never fails — there is always one more knob to turn. It is also worth documenting the result regardless of the outcome: a 'this does not work' is a valuable result when it is reasoned and prevents an investment.

A concrete case: a business wants to read incoming supplier invoices automatically and hand them to its accounting system. The risky assumption is not the interface but the recognition quality across the PDF formats that actually arrive, and whether the accounting software offers a dependable API. The PoC takes a hundred real invoices from the last quarter, runs them through the planned processing and measures how many fields come out correctly. That result decides the project — before any discussion about scope, roles and design.

The most common failure pattern is the PoC that goes into production. Because it 'already runs', it gets extended rather than rewritten: no tests, no error handling, hard-coded credentials and assumptions that only hold for the test data set. That is the classic origin of technical debt which then charges interest for years. The clean route is the opposite: run the PoC, record the finding, throw the code away and build the durable solution afresh with what you learned. Anyone unwilling to do that has to build the PoC differently, and more expensively, from the start.