The proof of concept that should have stayed a spreadsheet

A proof of concept is supposed to answer a question you cannot answer any other way. A lot of AI proofs of concept answer a question a spreadsheet could have settled in an afternoon, at a hundredth of the cost, with none of the engineering time. The build feels like progress because there is something running at the end. What you actually bought was an expensive way to learn something a simpler test would have told you first.

The demo that proved nothing new

A founder building an AI-native business intelligence platform described a habit he had to break in his own team. When a customer asked whether AI could predict some outcome from their data, the instinct was to build a small model and demo it. It looked convincing and it took weeks. IDC has found that roughly 88% of AI proofs of concept never reach production, and his early ones were quietly feeding that number.

He changed the first move. Before building anything, his team would pull the customer’s data into a spreadsheet and check by hand whether the signal was even there. Was there a relationship between the inputs and the outcome that any method could find. Often the answer was no, and they learned it in a day instead of a month. The proof of concept that would have followed would have proved only that the model could not find a pattern that did not exist. The spreadsheet answered the real question, which was whether the question had an answer at all.

Separate the data question from the AI question

A finance leader at a manufacturing company gave me the discipline in plainer terms. Every AI proposal that crossed her desk got one test before it got a budget. Could a competent analyst produce a rough version of this in a spreadsheet in a day. If yes, that came first, always, because it told her whether the underlying idea held before anyone spent on the sophisticated version.

She was not against building. She was against building to discover something a cheaper tool would have surfaced. Half the proposals died at the spreadsheet stage, and she counted every one as money saved rather than a project lost. The other half passed the manual check and earned a real proof of concept, which then had a much better chance of reaching production because the core question was already settled. She said the spreadsheet was not a lesser version of the AI project. It was the test that told her whether the AI project was worth starting.

A quick filter before you greenlight a proof of concept:

Ask what question the build answers. If you cannot state it in a sentence, you are building to look busy.
Try the manual version first. A spreadsheet or a day of analysis often answers the real question for almost nothing.
Separate “is the signal there” from “can AI use it.” The first is cheap to check and gates the second.
Set the bar before you build. Decide what result would make you continue, so the demo cannot just look impressive and move on.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, one of the least glamorous things we do is run the cheap test before the expensive one. We check whether the data even supports the outcome a team wants, often by hand, before recommending a single line of model code. Sometimes that check ends the conversation and saves a quarter of build. Sometimes it confirms the signal is real and the proof of concept starts on solid ground. Either way the team learns it for the price of a diagnosis, not the price of a build.

A proof of concept should earn its cost by answering something cheaper tests cannot. Run the spreadsheet first, and let it tell you whether there is anything worth building.