Proof of concept
Based on Wikipedia: Proof of concept
In 2005, Robert Rodriguez walked into a Hollywood meeting with something unusual: a short film. It was barely six minutes long, shot entirely against a green screen, featuring just two characters in a grimy bar. The footage looked like nothing else being made at the time—stark black-and-white with splashes of vivid color, comic book panels come to life. Rodriguez wasn't there to pitch an idea. He was there to prove that his vision for Sin City could actually work.
That short film became the opening scene of the final movie.
This is the essence of a proof of concept: not just describing what you want to build, but demonstrating that it can exist. It's the difference between saying "I think this is possible" and showing someone a working fragment of the thing itself.
The Origin of Proving Things
The term "proof of concept" has been kicking around since at least 1967, but it crystallized in meaning during the space race era. In 1969, a Congressional subcommittee on Advanced Research and Technology offered this definition: a phase in development where experimental hardware is constructed and tested to explore and demonstrate the feasibility of a new concept.
Notice what's packed into that definition. This isn't a finished product. It's not even necessarily a good version of the product. It's hardware built specifically to answer a question: can this thing work at all?
Twenty years later, an electronics engineer named Bruce Carsten claimed to have coined the phrase "proof-of-concept prototype" in 1984. He used it to describe something very specific: a circuit built to demonstrate that a new design or fabrication technique was feasible. Crucially, this prototype was never intended to become an early version of the production design. It existed purely to prove a point and then be discarded.
This distinction matters. A proof of concept isn't a rough draft of your final product. It's a question asked in physical form.
The Language of Early Experiments
Before we go further, let's untangle some related terms that often get confused with proof of concept.
A breadboard is a term from electrical engineering dating back to 1940. Literally, early electronics hobbyists would nail components to wooden breadboards from their kitchens to test circuits. Today, a breadboard is any temporary assembly used to test a circuit design—something you build knowing you'll tear it apart.
A prototype is further along the development path. It's a working model that resembles what the final product might look like. An engineering prototype is more refined still—something you'd show to manufacturing to say "build something like this."
A brassboard sits somewhere between breadboard and prototype. It's more polished than a breadboard but not yet production-ready. The term comes from early electronics when engineers would mount components on brass plates.
And then there's the proof of value, a close cousin that shifts the focus from "can we build this?" to "will anyone want it?" A proof of value demonstrates potential customer use cases rather than technical feasibility. It's usually less detailed than a proof of concept but more focused on the human element.
Hollywood's Proof of Concept Problem
The film industry has embraced proof of concept filmmaking with particular enthusiasm, and for good reason. Movies are expensive gambles. A studio might spend hundreds of millions of dollars on something that exists only as words on paper and images in a director's mind. Proof of concept films let everyone see a fragment of the vision before committing those resources.
Sky Captain and the World of Tomorrow was one of the first major films shot entirely against green screens, with nearly every background and prop added by computer afterward. Before the studio would fund it, director Kerry Conran created a proof of concept film demonstrating the visual style. The same approach made 300 possible—Zack Snyder showed producers what Frank Miller's graphic novel could look like as moving images.
Pixar has turned this into an art form. Their short films often serve as laboratories for techniques they'll later use in features. Geri's Game, that delightful five-minute piece about an old man playing chess against himself in a park, wasn't just storytelling. It was Pixar teaching themselves how to animate cloth and human facial expressions—skills they'd need for Toy Story 2.
Before Finding Nemo, Pixar created several proof of concept shorts to work out the technical challenges: how to make water move convincingly, how to animate sea anemone tentacles, how to reveal a whale slowly emerging from darkness. Each short answered specific questions that the feature film would ask at scale.
Engineering and the Funding Gap
In engineering, proof of concept often means building something rough and functional with whatever materials are at hand. An electrical device might be assembled on a literal breadboard—a plastic grid with holes for inserting wires and components—just to prove the underlying concept works.
Patent applications frequently require this kind of demonstration. It's not enough to describe an invention; you often need to show that it functions. The patent office wants evidence that you've moved beyond pure imagination.
Universities have recognized this as a critical bottleneck in bringing research to market. Many have established what they call proof of concept centers, specifically designed to address the "funding gap" in early-stage research. This gap exists because the work is too speculative for traditional investors but too applied for basic research grants. Proof of concept centers provide seed funding for novel research that no conventional source would touch, helping accelerate the journey from laboratory discovery to commercial product.
The Sales Dance
In business and sales, proof of concept takes on a different character. Here, a vendor might let a prospective customer try their product in a controlled setting. The goal isn't just to demonstrate that the technology works—it's to establish that it works for this particular customer's needs.
This process helps isolate technical issues that might arise in the customer's specific environment. It provides data for budgeting decisions. It gives the customer confidence that they're not buying a promise.
Companies often deploy specialized sales engineers for these demonstrations—technical experts whose job is to ensure the vendor puts their absolute best foot forward. These aren't typical salespeople making pitches. They're problem-solvers working to prove that a solution exists for the customer's specific challenges.
Security and the Art of Breaking Things
In computer security and encryption, proof of concept means something more dangerous and more elegant. It's a demonstration that shows how a system can be protected—or compromised—without building a complete attack vehicle.
Consider a security researcher who discovers a vulnerability in Windows. They might create a proof of concept exploit: a minimal piece of code that demonstrates the vulnerability is real and exploitable. This code isn't optimized, isn't polished, and couldn't be used in a real attack without significant additional work. But it proves the danger exists.
Winzapper was exactly this kind of tool. It possessed the bare minimum capabilities needed to selectively remove an item from the Windows Security Log—nothing more. No one would use Winzapper for an actual attack; it was too crude. But it proved that such attacks were possible, which mattered enormously for the people defending Windows systems.
This creates an interesting ethical tension in security research. Publishing proof of concept code helps defenders understand and patch vulnerabilities. But it also gives attackers a starting point. The security community has developed norms around responsible disclosure partly to navigate this dilemma—giving vendors time to patch before proof of concept code becomes public.
Software Development's Three Stages
In software development, "proof of concept" often characterizes several distinct processes with different objectives. These stages deserve careful distinction because they serve different masters.
First, internal technical teams might build a proof of concept to determine whether their proposed system can satisfy its intended purpose. This is asking: can we build what we're imagining?
Once the team is satisfied, they develop a prototype—something more polished that can be used to seek funding or demonstrate capabilities to prospective customers. This is asking: will anyone pay for what we've built?
The United States General Services Administration, the federal agency that handles government procurement, has even created a formal checklist for defining an Agile software proof of concept. It requires clear definitions of the problem being solved, specification of what input the proof of concept needs before it can begin, and explicit output criteria—including what success looks like.
This bureaucratic formalization might seem like overkill, but it reflects hard-won wisdom. Too many proof of concept projects fail not because the technology doesn't work, but because no one agreed on what "working" meant.
Why Bother Proving Concepts?
The key benefits of proof of concept in software development cluster around risk reduction and learning.
First, it helps teams choose the right technology stack. Before committing to a particular programming language, database, or framework, you can build a small proof of concept to see how well these tools handle your specific challenges.
Second, it increases the probability of attracting investor interest. A working demonstration, however rough, is infinitely more compelling than a slide deck.
Third, it simplifies testing and validating ideas. Rather than building an entire system only to discover a fundamental flaw, you can test core assumptions early and cheaply.
Fourth, it generates valuable feedback from your target audience before you've invested in building a full-scope system. Users can interact with something tangible rather than imagining based on descriptions.
Fifth, it can onboard early clients before you've officially released. Some customers are willing to work with rough versions of products if they believe in the vision—and these early adopters often become your most loyal advocates.
Steel Threads and Pilot Projects
Two related concepts deserve attention: the steel thread and the pilot project.
A steel thread is a technical proof of concept that touches every technology in a proposed solution. Imagine you're building a system that involves a mobile app, a web server, a database, and a third-party payment processor. A steel thread would be a tiny implementation that connects all these pieces—not to do anything useful, but to prove they can talk to each other.
The name evokes the idea of a thread of steel running through the entire architecture, thin but unbroken. By contrast, a proof of technology focuses on just one technical problem—like how two systems might integrate—without attempting to connect everything.
A pilot project is different still. It refers to an initial deployment of a system into actual production, but with limited scope. You might restrict which users can access it, or which business processes it affects, or which partner organizations are involved. The purpose is to test the system in real conditions while limiting the damage if something goes wrong.
The distinction matters: a proof of concept asks "can this work?" A pilot project asks "does this work in the real world?"
Video Games and Tech Demos
The video game industry has its own proof of concept tradition: the tech demo. These are demonstrations designed to prove that specific graphical or gameplay capabilities are achievable.
A tech demo might show off a new physics engine by rendering thousands of falling objects that bounce and collide realistically. Or it might demonstrate a new lighting technique by walking through a virtual cathedral at different times of day. The demo isn't a game you'd want to play—it's evidence that a certain technical achievement is possible.
Game developers use tech demos both internally (to prove to themselves they can deliver on ambitious plans) and externally (to generate excitement and attract funding). Some tech demos become legendary in gaming culture, remembered years after the games they previewed have come and gone.
A Special Case: Drug Development
In pharmaceutical development, proof of concept means something quite specific—and confusingly, it's not the same as proof of principle. This is one of those cases where terms that seem synonymous in everyday English have distinct technical meanings.
To understand these distinctions, you need to understand how drug development works. Early in the process, researchers can't directly measure whether a drug effectively treats disease. Instead, they use surrogate endpoints—measurable indicators that suggest the drug might work.
For example, you can't quickly determine whether a new antibiotic cures pneumonia. That would require treating patients and waiting to see if they recover. But you can measure whether the drug kills bacteria in laboratory tests, or whether it reduces fever in infected patients. These surrogate endpoints guide decisions about whether to proceed with further testing.
Similarly, a new blood pressure medication might be tested by measuring whether it actually lowers blood pressure—a surrogate endpoint for the real goal, which is preventing strokes and heart attacks. If the drug can't lower blood pressure, there's no point testing whether it prevents strokes.
Proof of Mechanism
Proof of mechanism, often abbreviated PoM, relates to the earliest stages of drug development—often before any testing in humans or even research animals. It asks: does this drug interact with its intended molecular target?
A drug designed to block a specific enzyme should actually block that enzyme. A drug meant to activate a particular receptor should activate it. Proof of mechanism demonstrates this basic molecular interaction occurs and affects cell biochemistry in the desired direction.
Proof of Principle
Proof of principle, or PoP, comes next and typically refers to early clinical development. It evaluates whether the treatment affects disease biomarkers—measurable biological signs of the condition—but not necessarily the clinical endpoints that patients care about.
If you're developing a diabetes drug, proof of principle might show it affects blood sugar levels. That's a biomarker. Whether the drug actually prevents the complications of diabetes—blindness, kidney failure, heart disease—is a clinical endpoint that takes much longer to establish.
At the proof of principle stage, companies decide whether to push forward with more extensive (and expensive) testing or to abandon the drug.
Proof of Concept in Pharma
Proof of concept in drug development refers specifically to early clinical development, conventionally divided into Phase I and Phase IIA trials.
Phase I trials typically involve a small number of healthy volunteers receiving single doses or short courses of treatment—perhaps up to two weeks. These studies aim to show that the drug has some of the desired clinical activity, that humans can tolerate it, and to identify dose levels worth studying further. Other Phase I work investigates how the drug is absorbed, distributed, metabolized, and excreted—the pharmacokinetics that determine how the drug behaves in the body.
Phase IIA trials expand to perhaps a hundred patients who actually have the disease of interest. Now the questions become more ambitious: does the drug produce a useful amount of the desired effect? Can patients tolerate it over the long term? Which doses might eventually be marketed?
After Phase IIA, another decision point arrives. Many drugs die here, having proved they work a little but not enough to justify further development.
The Long Road After Proof
For drugs that survive proof of concept, the journey continues through Phase IIB and Phase III trials. These involve larger numbers of patients across multiple medical centers, treated at doses and durations representative of eventual marketed use. Patients are randomly assigned to receive either the experimental drug or a placebo—or sometimes an existing treatment for comparison.
Phase III aims to produce convincing, statistically significant evidence that the drug actually works. It also provides a better assessment of safety than smaller, shorter trials can offer. Rare side effects that occur in one patient per thousand won't show up reliably in trials of a hundred patients.
At the end of Phase III, companies apply to regulatory authorities—the Food and Drug Administration in the United States, the European Medicines Agency in Europe—for permission to market the drug outside of clinical trials.
Even after approval, clinical trials can continue. Post-marketing studies might investigate how the drug works alongside other medications, explore additional uses, or better characterize rare safety concerns that only emerge with widespread use.
The Courage to Build Small
There's something almost paradoxical about the proof of concept. To build something great, you must first be willing to build something small and incomplete. You must accept imperfection not as a compromise but as a strategy.
Rodriguez didn't try to convince Hollywood executives that Sin City could work by showing them elaborate storyboards or detailed budgets. He showed them six minutes of actual film. Pixar didn't promise they could animate cloth; they made Geri's jacket move convincingly. Security researchers don't write theoretical papers about vulnerabilities; they demonstrate exploits.
The proof of concept is an act of intellectual humility combined with practical boldness. It acknowledges that nobody—including the builder—knows for certain whether an idea will work. And it responds to that uncertainty not with more speculation but with action: build something small, learn from it, and let the demonstration speak.
In an age of elaborate business plans and detailed specifications, there's something refreshingly concrete about asking the simplest possible question: can you show me it works?