Skip to content
All posts

Blog

Build vs. Buy: Should Your Architecture Firm Build Its Own AI, or Buy the Platform?

It is one of the most common questions we hear from larger firms, and it is a fair one. If you have a computational design team, you have probably already wired some AI into Revit yourselves. Maybe it works. Maybe people love it. So why pay for a platform?

Our honest answer tends to catch people off guard: you are right, you should keep building. Firms like Gensler, Perkins&Will and Stantec have genuinely talented computational teams, and a lot of what they build should stay in-house. We do not think “build or buy” is even the right question.

The better question is what to build, and what to buy.

It was never build versus buy. It is what to build and what to buy.

Most build-versus-buy advice lands in the same place: build the things that make you different, and buy the things that are standard. If a capability is a real differentiator for your firm, owning it makes sense. If it is common infrastructure that every firm needs and nobody wins business on, you are usually better off buying it. As one widely used framework puts it, building something outside your core competency means replacing years of someone else’s iteration with your own assumptions.

For an architecture firm, the differentiator is your design intelligence: your workflows, your standards, your detailing logic, the way your best people solve problems. The infrastructure underneath an AI tool is not that. It is the same problem every firm in the world is solving on its own.

Architects are not software companies

After an internal tool succeeds, the team that built it picks up a second job nobody asked them to take on. Security. QA. Releases. Version compatibility. User support. Monitoring. Uptime. None of that is what they were hired to do, and all of it now has their name on it.

The bigger cost is not the first version. It is everything after. By various industry estimates, maintenance accounts for somewhere between 60 and 80 percent of a software product’s total lifetime cost, not the initial build (ScienceSoft, with similar ranges long cited by Gartner and the IEEE). Every Revit release, every model update, every API change and every new security requirement means someone has to go back in and keep the thing running, and that work does not stop.

A weekend demo is not an enterprise system

Connecting a large language model to the Revit API over a weekend is genuinely easy now. Making that safe for two thousand architects working on live projects is a different kind of problem.

An AI agent with write access to a model can do real damage if the right limits are not in place. It can delete elements, overwrite work, or confidently produce something that was never there. On a $500M project, a single mistake like that costs more than years of any software subscription. The hard part of enterprise AI is not getting it to act. It is getting it to act safely every time, with guardrails, permissions, audit trails and rollback built into the system rather than bolted on after the fact.

The one-person problem

There is a quieter risk too. Internal tools often end up resting on a single person, the one computational designer who understands how the whole thing fits together. Engineering teams call it the “bus factor”: how many people would have to leave before the project stalls. When the answer is one, you do not really own a platform. You own a dependency. That person changes teams, goes on leave, or takes another job, and the tool everyone relied on stops moving.

The five-year question

This is where the decision gets clearer. The honest question was never whether you can build it. Almost any large firm can. The question is what your most talented people should be doing with the next five years.

The economics back this up. The initial build is the small part of total cost of ownership. The ongoing operation is where the money actually goes (IBM has a clear primer on the concept, and CIO walks through how to calculate it). Every hour your computational designers spend maintaining infrastructure is an hour they are not spending on the work that makes your firm worth hiring.

The strategy that wins: build what is strategic, buy what is standard

The strongest firms we work with do not pick a side. They run a hybrid model. They keep the strategic, firm-specific work in-house, where their advantage actually lives, and they buy the enterprise-grade platform underneath it, so their people never become a software vendor by accident. Separating what is standard from what is strategic is the practical way to apply build-versus-buy without giving up control of either one.

That is the role we are built for. SWAPP is the secure, enterprise-ready AI layer for Revit and ArchiCAD: ISO 27001 certified, with SSO, granular permissions, isolated firm knowledge, customer-specific context, tested releases and support across multiple Revit versions. It is the kind of foundation that takes years to build internally, already built, so your team can work on top of it instead of underneath it.

Where to draw the line

Every major architecture firm should have a strong computational design team. Their mission is to make the firm unique. Our mission is to give them a platform they can build on, without turning architects into a software vendor. Asking one team to do both is a heavier strategy than it looks, and it usually costs more than the license ever would.

So the question to bring to your next planning conversation is not whether you can build your own AI. It is where you want to draw the line between what you build and what you buy.

See SWAPP run a live project. Yours.

Every engagement starts with a pilot on your own projects and your own standards. Watch SWAPP execute real production work inside Revit, then decide.