Most small-firm software projects fail for one reason, and it is not budget or talent — it is scope. A small commercial real estate firm starts every technology project holding the winning hand: small, tightly scoped projects succeed roughly 90% of the time while large, sprawling ones succeed less than 10%. Then the firm throws that hand away by scoping its first custom AI automation the way a large enterprise would — everything at once, a platform instead of a workflow, a feature list instead of an outcome. The scoping fix is not more planning or a better vendor. It is deliberately keeping the project small enough to stay on the winning side of that statistic. What follows is the honest version of why these projects go sideways for a 4-to-20-person shop, and the scoping discipline that keeps yours out of the failure column.
The failure rate you are actually up against
The headline statistics are grim on purpose. Depending on which vendor blog you read, 70% to 75% of software projects are described as failed or at risk, and the Standish Group’s long-running research splits IT projects into roughly 31% successful, 50% challenged, and 19% outright failed. Those numbers get quoted to scare buyers into hiring a bigger firm or buying a bigger process.
Read the same research one layer deeper and the story flips in your favor. The strongest predictor of success is not the team, the methodology, or the budget — it is size. Small projects come in around a 90% success rate; large, complex ones fall below 10%, and complexity driven by size and conflicting goals is what actually kills projects.
That is the fact a small firm should tape to the wall. Against an institutional competitor with a technology budget and an IT department, you are not disadvantaged on this metric — you are advantaged, because your projects are naturally smaller. The failure rate that applies to you is the small-project rate, unless you talk yourself into an enterprise-sized project.
What goes wrong when projects fail is consistent: incomplete requirements, changing requirements, and weak user involvement top the list every time, and the Project Management Institute’s research shows scope creep runs high wherever project discipline is thin. None of that is a technology problem. It is a scoping problem — and scoping is the one part you control before a dollar is spent or a vendor is hired.
Where small firms throw away their built-in advantage
Small firms lose the size advantage by importing scoping habits from companies that operate nothing like them. Three patterns account for most of the damage.
They scope a platform when they need a workflow. The brief starts as “we want a tool that helps with our deals” and grows into “it should do everything Yardi and Dealpath do, but for us” — a multi-year enterprise build described in a sentence. The firm that would have succeeded automating one workflow — lease abstraction, rent-roll reconciliation, first-pass deal screening — instead scopes a system and lands in the sub-10% column.
They write a feature list instead of an outcome. A feature list has no natural end: every feature suggests three more, and because nothing defines when the project is done, it never is. The build drifts, the invoices keep coming, and the firm cannot tell whether it is 60% finished or 90% because “finished” was never defined in terms an owner could check.
They skip the question of who keeps it running. A large enterprise has staff to maintain what it builds; a 4-to-20-person firm usually does not, so a system that shipped fine becomes an orphan the first time a document format changes or an integration breaks. Scoping a build you cannot maintain is scoping a future emergency — a point we cover in when it makes sense to leave a proptech vendor and build your own.
Each of these quietly turns a small, winnable project into a large, losing one, and to a non-technical principal the drift is hard to see until the money is gone. The fix is to refuse the inflation at the scoping stage.
The scoping fix, in five moves
The scoping fix is a discipline you apply before hiring anyone — five moves meant to make the project smaller, not more thorough.
1. Scope to one workflow, not a system. Name the single most painful, repetitive task in your firm — summarizing leases, reconciling a rent roll, drafting first-pass listing copy, triaging inbound deal emails into your pipeline. Scope the project to that one workflow and nothing adjacent. If the brief names two workflows, it is two projects; do the more painful one first and let it prove the approach before you touch the second.
2. Write the outcome as a sentence an owner can check. Not “an AI tool for lease review” but “a lease summary I can trust for the ten fields I actually pull, in under two minutes, that I spot-check rather than redo.” That sentence is your whole specification: it names the job, the standard, and the time saved, and anyone can tell whether it was met.
3. Size the first build to match the small-project success rate. For a scoped custom automation covering one workflow, the current market runs roughly $25,000 to $150,000 depending on complexity. Aim at the small end of that range for a first project. A smaller first build is not timidity; it is choosing the 90% success rate on purpose. The full budgeting logic sits in our guide to how much a small CRE firm should budget for AI each year.
4. Name the maintainer before you start. Point to the specific person — inside the firm or a standing outside relationship — who keeps the automation working when a document changes or an integration breaks. If you cannot name them, the scope is wrong: you are scoping something with no one to own it. This one question ends more bad projects than any technical review.
5. Phase everything after the first workflow. The first project proves the approach on one job; everything else waits behind it, scoped as its own small project only after the first has actually saved time in production. Phasing keeps every future project on the small-and-winnable side of the line instead of merging them into one large-and-losing build.
None of these moves ask you to plan harder or gather more requirements. They ask you to want less at once — which runs against the grain of failure-scare marketing, but is the entire fix.
Big-firm scoping versus small-firm scoping
The two approaches diverge at the very first decision, and that divergence sets the odds before any work begins.
| Decision | Big-firm scoping (fails for you) | Small-firm scoping (wins for you) |
|---|---|---|
| Unit of work | A platform or system | One workflow |
| Specification | A feature list with no defined end | One outcome sentence an owner can check |
| First build size | As large as the budget allows | Deliberately small — the low end of the range |
| Definition of done | Vague, discovered late | A measurable accuracy and time bar, set up front |
| Maintainer | Assumed to exist | Named before the project starts |
| Everything else | Bundled into one build | Phased as separate small projects |
| Resulting odds | The sub-10% large-project rate | The ~90% small-project rate |
The difference between the columns is not effort or intelligence. It is which success rate you signed up for.
Define done before you write a check
The scoping move that matters most, and the one most firms skip, is defining “done” — and custom AI automation makes it harder than ordinary software does.
Traditional software is deterministic: done means the feature exists and the button works. AI automation is probabilistic — the same lease summarizer will be right almost always and occasionally wrong, so “it works” is not a yes-or-no. Done has to be an accuracy and reliability bar you set in advance: “extracts the ten fields I use accurately enough that spot-checking beats redoing, on the messy documents we actually receive, not clean samples.”
Set that bar in writing before you write a check, using your own real documents. A vendor demo on a clean sample proves nothing about your scanned, initialed, marked-up PDFs, so insist the pilot run against a representative slice of your genuine files — including the ugly ones. A written, testable finish line cannot drift indefinitely; without one, a project drifts until the budget is gone, which is the mechanism behind most of the failure statistics. Proving value on a small, real test before committing is the same discipline that governs a healthy pace of AI spending, laid out in our comparison of workshop-first versus software-first sequencing.
Should this be a build at all
The most valuable scoping decision is sometimes to not scope a build at all. Before you fix how a project is scoped, confirm the project should exist.
For a small CRE firm, three cheaper options sit in front of a custom build, each solving a large share of “we need software for this” problems with no project to fail. An off-the-shelf proptech tool may already do the job for a subscription — the honest test of when off-the-shelf is enough runs through our buy-vs-build playbook for small CRE firms. A thin workflow using ChatGPT, Claude, or Microsoft Copilot with saved prompts can cover a single weak task alongside the tools you already run. And often the real gap is fluency, not software — a fluent team handles the task by hand in a fraction of the time.
A custom build earns its place only when a workflow is central to how you win, no vendor fits it, and a thin workflow cannot cover it — the rare case, not the default. A build feels like taking control, but a build you did not need is not control; it is a project with a failure rate you volunteered for. The same low-overhead discipline that lets a small firm out-operate a larger competitor — doing less, but doing it exactly — runs through the manifesto on how small CRE firms punch above their size. Scoping software is one more place that discipline pays.
Frequently asked questions
Why do most small-firm software and AI projects fail?
They fail because of scope, not budget or talent. The strongest predictor of software project success is size: small, tightly scoped projects succeed roughly 90% of the time, while large, sprawling ones succeed under 10%. Small firms start with that advantage and lose it by scoping their first custom automation like an enterprise — a platform instead of a workflow, with no finish line and no named maintainer. The failure is decided at the scoping stage, before any code is written.
Are small companies better or worse at software projects than large ones?
Better, on the metric that matters most. Standish Group research finds project size is the strongest predictor of success, with small projects succeeding at roughly 90% versus under 10% for large ones. A 4-to-20-person firm naturally runs smaller projects, so it starts advantaged — but that advantage only survives if the firm resists inflating a small project into a large one by scoping a platform instead of a single workflow.
How do I scope a custom AI automation so it does not fail?
Make it smaller on purpose. Pick the single most painful, repetitive workflow and scope only that. Write the goal as one outcome sentence an owner can verify — “a trustworthy lease summary of my ten key fields in under two minutes.” Size the first build to the low end of the market range, name the person who will maintain it, and phase every other idea behind this one. Each move keeps the project on the 90% side of the success statistic.
What does “done” mean for an AI automation project?
Done is an accuracy and reliability bar you set in advance, not a feature that exists. Because AI automation is probabilistic, it will be right almost always and occasionally wrong, so “it works” is not yes-or-no. Define done as clearing a specific standard on your own real documents — your key fields extracted accurately enough that spot-checking beats redoing, tested on the messy files you actually receive. That written, testable finish line is what stops a project from drifting until the budget runs out.
Should a small CRE firm build custom software at all?
Usually not first. Three cheaper options sit in front of a custom build: an off-the-shelf proptech tool that already does the job, a thin workflow using ChatGPT, Claude, or Microsoft Copilot with saved prompts for a single task, or building your team’s fluency so the task takes minutes by hand. A custom build earns its place only when a workflow is central to how you win, no vendor fits it, and a thin workflow cannot cover it — confirm the project should exist before you scope it.
How much should a first custom automation cost, and how big should it be?
For a scoped automation covering one workflow, the current market runs roughly $25,000 to $150,000 depending on complexity, and a first project should aim at the low end deliberately. A smaller first build is a choice to sit on the 90% small-project success rate rather than the sub-10% large-project rate. Resist the urge to bundle several workflows to “get more value” from one engagement — bundling is exactly how a winnable small project becomes a losing large one.
Who maintains a custom automation after it ships?
Whoever you named before the project started — and if you cannot name them, the scope is wrong. A custom system needs someone to keep it working when a document format changes, an integration breaks, or the model updates. Large firms have staff for this; most small firms do not, which is why an orphaned build is a common failure mode. Naming a maintainer is a scoping requirement, not an afterthought.
What is the single most common scoping mistake?
Scoping a platform when you needed a workflow. The brief starts as help with one task and swells into a system that should “do everything our proptech does, but custom.” That one move converts a small, winnable project into a large, losing one before work begins. The countermove is to name one workflow, scope only that, and phase everything else behind it.
Where to start
The first decision is not which developer to hire or which platform to specify. It is whether you have a project at all, and if you do, how small you can make it while still solving a real problem. A free AI-readiness assessment produces exactly that read: a short working session that identifies your most painful workflow, tests whether an off-the-shelf tool or a thin workflow already solves it, and — if a custom build is genuinely warranted — helps you scope it to one outcome you can measure, at a size that sits on the winning side of the failure statistics. It is the cheapest way to make sure your first software project is one of the ones that works. Book a free AI-readiness assessment before you scope anything.
Arthur Wandzel
