Almost no AEC firm should build AI tools, and the exceptions are narrower than the people proposing them believe. Buy the general capability, buy the domain tools where they exist, and reserve building for the one place it genuinely pays: thin connective work between systems you already own, built by someone who will still be at the firm in two years.
The build conversation usually starts the same way. Someone technical inside the firm assembles a working prototype over a few weekends, demonstrates it, and it is genuinely impressive. The prototype is not the problem. The problem is that a prototype is roughly a tenth of the work and none of the ongoing obligation.
What building actually costs
The visible cost is the build. The real cost is everything after it, and it does not end.
The prototype gets you to a demo, not to production. Between them sit error handling, permissions, the cases your test files did not contain, and the fifty ways real project data differs from clean sample data. In my experience that is where most internal tools quietly die: they work for the person who built them and fail for the third user.
Model and platform churn is relentless. The underlying models and their APIs change on a cadence measured in months. A commercial vendor absorbs that as their business. You absorb it as an interruption to whoever built it, forever, and that person has billable work.
Support has no exit. Once a tool is in a workflow, someone owns it at 6pm on a deadline. In a firm without a software function, that someone is a project engineer, and the cost lands on utilization where nobody sees it as a software cost.
The bus problem is severe. Internal tools in professional services firms are usually one person deep. When that person leaves, and eventually they do, you have an undocumented dependency inside a production workflow and nobody who understands it.
None of these appear in the enthusiasm phase. All of them are the reason the honest first-year number for building is far above the license fee you were comparing it to, which is the same lesson as what AI actually costs an engineering firm: internal time is the largest line and it is the one nobody quotes.
The four-question test
Build only if you can answer yes to all four. Three out of four is a no.
- Does no product do this? Not "no product does it exactly our way." No product does it. Firms routinely propose building something that exists because evaluating the market is less fun than building. Run a real four-week evaluation first, and be honest about whether the gap is capability or preference.
- Is the thing you would build genuinely proprietary to you? Your workflow, your data structure, your integration between two systems you happen to own. If what you would build is generic, someone will productize it and undercut your maintenance cost within a year.
- Do you have a named owner with committed, protected hours? Not a volunteer, not "we will find the time." A person, an allocation, and a backup. If you cannot name the backup, you have failed this question.
- Would you still do it if it took three times longer and needed maintenance forever? Because it will, and it does. This is the question that kills most proposals, and it should be asked before the enthusiasm rather than after the disappointment.
The narrow case where building wins
There is one, and it is worth taking seriously: thin glue between systems you already own.
A script that pulls submittal metadata from your project management system, formats it, and files it where your team expects. A routine that assembles a proposal skeleton from your own past-performance database. Something that moves data between two platforms nobody has bothered to integrate because your combination is unusual.
These qualify because they are small, they encode something genuinely specific to your firm, they fail safely, and no vendor will ever build them for your particular pair of systems. They also do not require you to become a software company. Keep them small, document them in a paragraph, and make sure two people understand each one.
Note what these are not: they are not AI products. They are automation with a model call in the middle, which is a far more achievable thing and where most of the practical value in a mid-size firm actually sits.
The middle option most firms skip
Between buying a product and building a system there is configuration, and it is underrated.
Most enterprise AI assistants now let you set up a persistent working context: your standard report language, your spec conventions, your firm's voice, reference material the tool consults every time. That is not building. It is a few days of a knowledgeable person's time, it requires no maintenance beyond keeping the content current, and it captures a large share of what firms imagine they need custom software for.
If your complaint about an off-the-shelf tool is that it does not know your firm, this is the answer, and you should exhaust it before anyone writes code. It is also reversible, which building is not.
The prototype is the cheap part. Ask who maintains it in two years, and whether that person knows they signed up.
How to handle the internal proposal well
When someone brings you a working prototype, the wrong responses are an immediate yes and a dismissive no. Both cost you.
Take the prototype seriously as evidence, because it is. Someone found a real problem and cared enough to solve it on their own time. That tells you the workflow is worth fixing and that you have someone motivated, both of which are genuinely valuable.
Then run the four questions with them rather than at them. Most of the time the honest conclusion is that a product exists, or that configuration gets ninety percent of it. Occasionally it is that this is real glue work worth twenty hours and a documented owner.
Either way, do not let the answer be a slow no. The person who built a prototype on their weekends is exactly who you want engaged in your adoption effort, and quietly starving the idea is how you lose them. Give them the pilot instead, which is the "owner in pain" that most failed pilots were missing.
What I would tell a principal
Buy the general assistant on enterprise terms for everyone. Buy one domain tool once a workflow has proven expensive enough to justify it, measured rather than asserted. Configure both properly against your own material, which is where the firm-specific advantage actually comes from. Build only thin glue, only with a named owner and a named backup, and only after the first three are exhausted.
That sequence leaves you with no undocumented dependencies, no maintenance obligation you did not choose, and the ability to change your mind when this market moves again, which it will.
If you have an internal proposal on the table and want an outside read before you commit a person to it, that is a useful thirty minutes. Our tool evaluation engagement covers the build-or-buy question with your actual candidates. Start a conversation.
← Back to insights