A working demonstration before engineering begins
In OpenAI’s Proaction case study, chief operating officer Colin Knudsen describes using Codex to build interactive sales demonstrations without a technical background. He reports making four to six demos a month, typically in 30 to 45 minutes each, and estimates that this avoids 40 to 60 hours of engineering work a month.
These are Proaction’s own estimates, not an independent productivity study. The company sells fleet-management software. It is not evidence that an agency, fashion brand or design studio will achieve the same result.
Why the example matters beyond fleet software
A static proposal asks a client to imagine how a service might behave. An interactive demonstration lets the client try an assumption: what happens after this choice, what information appears next, or what is missing from the journey. That makes it a potentially useful scoping tool for creative teams building digital experiences.
The distinction is between making an idea easier to discuss and making the finished product cheaper to deliver. The former can happen in a short session; the latter still depends on integrations, testing, accessibility, security and maintenance. A prototype should make those unknowns visible rather than conceal them behind a convincing interface.
Keep the estimate attached to the task
The case also describes time saved across Knudsen’s other daily work and progress in the sales process. Those measures cover different activities. They should not be added together as if they describe one pool of savings, or retold as a revenue increase.
For a production team trying a comparable approach, use cleared or fictional client material and label simulated features. Record how long the demo takes to prepare, then ask whether it changes the brief or exposes a decision. Leave the estimate for a production build to the people responsible for delivering it. The useful outcome is a better-defined commission, not a promise that a demonstration is already a product.