Proof of Concept
A throwaway build that answers one question: is this technically possible. Not a product, not an MVP, not something you ship to users.
A proof of concept exists to retire one specific technical risk. Can this model hit the latency we need. Will this integration actually work against the legacy system. Can we prove the cryptography before we design a product around it. A PoC answers "is this possible" and nothing else. It is built fast, judged on whether it works, and then thrown away.
The distinction that costs companies the most is PoC versus MVP versus prototype. A PoC answers "is this technically possible" and is aimed at your own team. A prototype answers "does this feel right" and is aimed at design and usability, often with no real backend at all. An MVP answers "will anyone actually use and pay for this" and is a real product, shipped to real users, just scoped to the smallest version worth their time. They have different audiences, different quality bars, and different definitions of done.
The common and expensive mistake is shipping a PoC as if it were production. The code that proved a thing was possible was written to prove a thing was possible: no error handling, no tests, no security review, shortcuts everywhere. When the demo impresses someone and the decision is made to "just ship it," you inherit all of that as your foundation. The honest move is to treat the PoC as the answer to a question, then build the real thing properly.
Wavect runs a PoC when there is genuine technical risk worth retiring before committing to a build. Most projects do not need one; they need a discovery phase that scopes the work. We will tell you which one you are looking at.