A proof of concept asks “can the technology do this at all?”, a pilot asks “does it work on our documents, at our volume, for a price we can live with?”, and production asks “will it keep working next quarter when no one is watching?” They are not three sizes of the same test. They are three different questions, asked in order, and each one exists to buy a single decision cheaply before you commit to the next. For a small commercial real estate firm, knowing which question you are actually answering is what keeps a promising demo from turning into an expensive mistake.
Most explanations of these three words are written for a company with a data team, a project manager, and a change-management budget. You have none of those. You are a principal, a managing broker, or an operations director at a firm of four to twenty people, the deal data is confidential, and the person who would run any of this is the same person who will live with whatever it produces. That changes what each stage has to be. The definitions below are the ones that hold up at your size — where “production” means a tool a busy broker relies on without thinking about it, not a system some IT department maintains for you.
Three Questions, Not Three Sizes
The most common mistake is treating proof of concept, pilot, and production as small, medium, and large versions of one thing. They are not. Each stage answers a question the previous stage could not, and skipping one means paying to answer a question you never asked.
A proof of concept answers a technical question: is this even possible? A pilot answers a business question: is it possible here, on our real work, at a cost that makes sense? Production answers an operational question: can we depend on it over time, without babysitting it? A tool can pass the first and fail the second — it reads a clean sample lease perfectly and falls apart on your scanned ones. It can pass the second and fail the third — it worked beautifully for six weeks and then quietly broke when a vendor changed a form. Because the questions are different, the tests are different, and the decision each one buys is different.
Reading the stages this way also tells you what not to over-invest in. A proof of concept does not need to be polished; it needs to be honest about feasibility. A pilot does not need to scale; it needs to survive your worst inputs. Production is the only stage that has to be dependable, because it is the only one people will actually lean on.
Proof of Concept: Can the Technology Do This at All?
A proof of concept is the cheapest, narrowest test that answers one question: can the technology perform the core task at all? Nothing more. You are not testing whether it fits your workflow, whether your team will adopt it, or what it costs to run. You are checking whether the underlying capability exists for your specific task, before anyone spends real money assuming it does.
For a real estate firm, a proof of concept is small and concrete. Take five representative lease PDFs, run them through a current AI tool, and see whether it can pull the twelve terms you care about into a table. Feed it three deal packages and check whether it can summarize the rent roll accurately. The sample is tiny, the setup is rough, and that is the point. A proof of concept that takes weeks and a budget has stopped being a proof of concept.
The output of this stage is a yes or a no, not a deployment. “Yes, it can read a lease and extract these terms” is a green light to design a real test. “No, it cannot reliably tell a base-year stop from an expense cap” is a red light that just saved you the cost of a pilot. What a proof of concept can never tell you is whether the thing is worth building — it only tells you the door is not locked. Deciding whether to walk through it is a separate question, and often the honest answer is that an off-the-shelf proptech tool already does this well enough that no custom build is warranted at all.
Pilot: Does It Work on Our Documents, at Our Volume?
A pilot is where the question stops being technical and becomes yours. It asks whether the capability a proof of concept demonstrated actually holds up on your real work: your messiest documents, your real monthly volume, at a run cost you can live with, judged against how you do the job today. This is the stage that separates a demo from a decision, and it is the stage most projects get wrong.
The difference between a proof of concept and a pilot is the difference between clean and real. A proof of concept can run on the tidy sample lease. A pilot has to run on the scanned lease with the handwritten rider, the rent roll a property manager built with merged cells, the forty-page deal package that arrives as mixed PDFs. Those edge cases are where automations break, and they are exactly the inputs you handle every week, so a pilot that avoids them has tested nothing you can use. It also needs a baseline — how long the task takes today and how often it produces an error — because “the AI is pretty good” means nothing without a number to beat.
A pilot is time-boxed and ends in a verdict. Two to four weeks, a defined accuracy bar, an end date set before it starts, and a decision at the deadline: build it, buy something instead, or leave it alone. The mechanics of running one well — the baseline, the test set, the acceptance bar, the go/kill gate — are worth studying in detail, and the full anatomy of a successful automation pilot walks through each part. For the purpose of these definitions, the thing to hold onto is that a pilot answers “does it work for us, and is it worth it?” A proof of concept never claimed to.
Production: Will It Keep Working When No One Is Watching?
Production is the stage where a tool stops being a test and becomes something your firm relies on to get real work done. The question it answers is not “does it work?” — the pilot settled that — but “will it keep working, reliably, when the person who ran the pilot has moved on to other things?” That is an operational question, and it is the one small firms most often forget to ask.
At your size, production does not mean an enterprise deployment with a dashboard and a support desk. It means the lease-abstraction tool is wired into the way your team actually works, someone owns it when it breaks, and the run cost is a known monthly line rather than a surprise. It means the automation handles this month’s leases without anyone re-testing it, and there is a defined step for the cases it flags as uncertain. Production is boring by design. The excitement belonged to the earlier stages; this one is about dependability.
Two things make production real rather than aspirational. The first is a clear owner — at a firm with no IT department, someone has to be responsible for the tool when a vendor changes a form or a model behaves differently, even if that owner is a support arrangement with whoever built it. The second is maintenance as a planned cost. Software that reads documents from the outside world drifts as those documents change, and a production tool needs a person and a small budget to keep it aligned. A pilot with no owner, no maintenance plan, and no place in daily work cannot cross into production no matter how well it performed — which is why so many promising pilots simply stall.
The Gates Between the Stages
Between each stage sits a decision, and the discipline of these three words is that you make the decision on purpose instead of drifting from one stage to the next. Each gate is a small, honest conversation about whether the question this stage answered justifies asking the next one.
- Proof of concept → pilot: Only move forward if the technology cleared the feasibility bar and the workflow is worth the effort of a real test — repetitive, high-volume, and painful enough that automating it would pay for itself. If the capability exists but the task is rare or low-stakes, the right call is to stop here.
- Pilot → production: Only move forward if the pilot beat your baseline against real inputs, the run cost is acceptable, and someone is willing to own the tool. A pilot that “mostly worked” but has no owner is not ready, however good the accuracy looked.
- Any gate → stop: A legitimate outcome at every gate is “no further.” A proof of concept can end a project by proving the technology is not there yet. A pilot can end it by proving an off-the-shelf tool already does the job. Treating “stop” as a failure is how firms end up building things they did not need.
The gates are what make the whole ladder cheap. Each stage is designed to be a fraction of the cost of the one after it, so you spend a little to decide whether to spend more, and the expensive commitment — a full build — only happens after two cheaper tests have earned it. Where a custom build fits in the bigger picture of tools you could buy instead is the subject of the broader buy-versus-build playbook.
The Two Ways Small Firms Get This Wrong
Almost every failed AI effort at a small firm is one of two mistakes, and both come from ignoring the ladder.
The first is skipping straight to production because a demo looked convincing. A vendor shows a slick example, it reads one lease flawlessly, and the firm commits to rolling it out across the team. Then it meets the real document pile and fails, having never been tested on anything messy. Gartner has predicted that around 30% of generative-AI projects are abandoned after the proof-of-concept stage, and a large share of those are projects that treated an early demo as if it were a finished product. The proof of concept was mistaken for the whole journey.
The second is pilot purgatory — a pilot that never ends. With no end date, no accuracy bar, and no gate, the test runs for months, consuming attention and budget while producing no decision. MIT’s Project NANDA, in its 2025 State of AI in Business report, found that roughly 95% of enterprise generative-AI pilots produced no measurable impact on the bottom line, and the common thread was not weak technology but weak design: no success criteria, no baseline, no feedback loop. A pilot with no gate is an unmanaged project wearing a pilot’s name. The fix for both mistakes is the same — decide, before you start each stage, exactly what question it answers and what result would end it.
What Each Stage Should Cost
Cost should climb with certainty. Each stage is meant to be far cheaper than the one after it, because the whole point of the ladder is to buy information before you buy a build. These are market ranges, not any single firm’s price list, and your numbers will vary with scope.
A proof of concept should be nearly free — often a few hours of someone’s time and the cost of a current AI subscription, because you are running a handful of documents through an existing tool to check feasibility. A pilot is a small, scoped engagement designed to cost a fraction of a full build, so a “don’t build” verdict stays affordable — think low thousands, in the same neighborhood as LLM fluency training for your team, which typically runs from a couple of thousand to the low tens of thousands depending on depth. A production custom automation is the real commitment: single-workflow custom builds generally start in the tens of thousands and rise with complexity, plus a recurring run-and-maintain cost each month.
The math is the reason to respect the sequence. A few thousand dollars spent on a proof of concept and a pilot is what makes it affordable to walk away before the tens-of-thousands build. A firm that skips the cheap stages pays the expensive one to learn what a pilot would have told it for a fraction of the price.
The Three Stages on One Page
| Proof of concept | Pilot | Production | |
|---|---|---|---|
| Question it answers | Can the technology do this at all? | Does it work on our real work, at our volume, for a price we can live with? | Will it keep working reliably over time? |
| Scope | A handful of sample documents | Real, messy documents at real volume | The live workflow, in daily use |
| Judged against | Feasibility only | A measured baseline of how you do it today | Ongoing reliability and run cost |
| Time | Hours to days | Two to four weeks, time-boxed | Ongoing |
| Relative cost | Nearly free | Low thousands | Tens of thousands to build, plus monthly run-and-maintain |
| Decision it buys | Is this even possible? | Build, buy, or leave it? | Can we depend on it? |
| A “no” means | The capability is not there yet | Off-the-shelf or manual is better | Not ready to be relied on |
Read down the “decision it buys” row and the logic of the ladder is clear: three cheap questions, asked in order, each one earning the right to ask the next, with the expensive commitment saved for last. If you are still deciding whether custom automation belongs in your firm’s toolkit at all, the wider map of the proptech landscape is a useful place to start before you run a single test, and the small-firm AI manifesto lays out how lean firms use this kind of discipline to out-operate much larger ones.
Frequently Asked Questions
What is the difference between a proof of concept and a pilot?
A proof of concept tests whether the technology can perform a task at all, using a small clean sample; a pilot tests whether it works on your real, messy work, at your real volume, for a cost you can live with. The proof of concept answers a technical question in hours or days for almost nothing. The pilot answers a business question over two to four weeks and ends in a build-or-don’t-build decision. Passing a proof of concept never means a tool is worth deploying — it only means the underlying capability exists.
What does “production” actually mean for a small firm?
Production means a tool your team relies on to get real work done, without re-testing it each time. At a firm with no IT department, that requires three things a pilot does not: the tool is integrated into how people actually work, someone owns it when it breaks, and the monthly run-and-maintain cost is a known line rather than a surprise. Production is the dependable, unexciting stage — the pilot proved it works, and production keeps it working.
Can we skip the proof of concept or the pilot?
You can, but skipping is the single most common reason small-firm AI projects fail. Jumping straight to a full deployment because a demo looked good is why Gartner predicted around 30% of generative-AI projects are abandoned after the proof-of-concept stage. Each stage answers a question the previous one could not, and skipping one means paying the expensive stage to learn what a cheap stage would have told you. The sequence exists to make walking away affordable.
How long should each stage take?
A proof of concept should take hours to a few days — if it needs weeks and a budget, it has stopped being a proof of concept. A pilot should be time-boxed to two to four weeks with an end date set before it starts. Production is ongoing by definition. The most dangerous stage for a small firm is a pilot with no end date, because an open-ended test consumes budget and attention without ever producing a decision.
What is “pilot purgatory” and how do we avoid it?
Pilot purgatory is a pilot that never ends because it was never given an end date, an accuracy bar, or a decision gate. It runs for months, produces no verdict, and quietly drains budget. MIT’s 2025 research found roughly 95% of enterprise generative-AI pilots produced no measurable impact, largely because they were designed this way. You avoid it by deciding, before the pilot starts, exactly what result would make you build, buy, or stop — and holding the deadline.
Is it a failure if a stage ends in “no”?
No — a well-run “no” is one of the most valuable outcomes the ladder produces. A proof of concept that proves the technology is not ready, or a pilot that proves an off-the-shelf tool already does the job, has saved you from an expensive build for a small fee. The stages exist to buy decisions cheaply, and a decision not to build is a decision worth paying for. Judge each stage by the quality of the decision it produced, not by whether it approved more spending.
How much should each stage cost?
Cost should climb with certainty. A proof of concept is often nearly free — a few hours and an existing AI subscription. A pilot is a small scoped engagement in the low thousands, deliberately cheap enough that a “don’t build” verdict is affordable. A production custom automation for a single workflow generally starts in the tens of thousands to build, plus a recurring monthly run-and-maintain cost. These are market ranges; your figures depend on scope, and any credible partner will give you all three before you start.
Who runs each stage at a firm with no IT department?
You own the design and the decision at every stage, even when someone else does the technical work. A proof of concept can often be run by one curious person with an off-the-shelf AI tool in an afternoon. A pilot may involve a builder, but you keep control of the workflow choice, the baseline, the test set, and the go/kill gate. Production needs a defined owner — internal, or a support arrangement with the builder — responsible for the tool when a form changes or it drifts.
Does a pilot always lead to production?
No, and it should not be designed to. A pilot is meant to be able to end in “don’t build” as honestly as in “build,” and a builder who treats any outcome except production as a failure is running a sales motion, not a test. A pilot leads to production only when it beat your baseline on real inputs, the run cost is acceptable, and someone will own the result. Any of those missing is a reason to stop at the pilot, not to push into production.
How does this apply to real estate specifically?
The stages map cleanly onto workflows like lease abstraction, rent-roll standardization, and first-pass deal screening. A proof of concept checks whether an AI tool can pull your twelve lease terms from a few clean PDFs. A pilot runs it against your worst scanned leases and merged-cell rent rolls at a month’s real volume, measured against how your analyst does it today. Production wires the winning workflow into daily use with an owner and a maintenance budget. The document-heavy, confidential nature of real estate work is exactly why the messy-input pilot stage matters so much.
Where to Start
Before you run a proof of concept, you need to know which of your workflows is worth testing in the first place — and in what order. That inventory is the real starting point: a ranked read on which tasks would pay for a custom build, which are better served by a subscription or a prompt library, and where the honest answer is to wait. That is what a free AI-readiness assessment produces — a working session that maps your firm’s workflows, flags the ones worth taking up the ladder, and returns a plan with real cost ranges. Book a free AI-readiness assessment if you want that map before you spend a dollar testing anything. If a build is not the right move, the assessment will say so, and you will still leave with a clear picture of which stage your firm actually belongs at today.
Arthur Wandzel
