Most professional services leaders evaluating AI platforms have priced what it costs to build one. Few have priced what it costs to keep one alive: the technical capabilities to maintain it, and the standards and governance to get an entire firm using it correctly.
The conversation we keep walking into looks roughly the same:
By the time leadership sits down to decide, the prototype works, the numbers favor building, and the people who would build it are ready to start. The decision is already leaning one way before anyone makes it.
The firms having this conversation are reasonably concluding they should build. Unfortunately, it’s the wrong conclusion, and they will only find out when they’re already too far down that road. The financial case that led them there priced the cost of building the platform, not the cost of everything else that comes with it.
The real choice is the one services leaders are hesitant to make. Stay a services company, or become a product company that does implementations on the side? Most services leaders never wanted to run a product company. The craft they built the firm on is services, not software. The leadership teams making this call right now mostly don't know that's the call they're making. They think they're choosing a platform. They're choosing what kind of company they run.
The firms that get this wrong don't simply lose money. They fall behind the firms that bought a platform built to keep pace as the frontier moves. They feel it within a few years, and by that point, they’ve already lost out.
Frontier models are now good enough that a competent engineering team can vibe-code parts of an AI platform in days. Most SIs with serious engineering muscle could ship a working prototype this quarter. Some firms that have already cobbled their own version together on horizontal AI platforms and a stack of point solutions are proof.
The build is the easy part.
What a firm sees when it scopes a build is the part above the waterline. A model, a prompt, a demo that worked on Tuesday. That part is affordable now, and it is what makes building look possible.
What keeps the platform upright sits below the waterline, out of view until the firm is already committed. There are three core elements down there, each one the work of a standing function rather than a project, and none of them is what gets priced when an SI asks what it would cost to build its own version.
The first below the line is just keeping up to date. The model layer is changing on a monthly, sometimes weekly, basis. The labs ship new capabilities, new pricing, new context windows, and new primitives at a cadence that is frankly overwhelming. The homegrown stacks we've watched ship in the past year are already a quarter or two out of date.
Keeping a solution at the frontier requires living and breathing it every day. It means not simply reacting to new model releases, but proactively and rigorously evaluating the evolving landscape, continuously refining the platform to ensure it remains the most effective solution given the current state of the frontier.At Auctor, we shipped infrastructure for durable, multi-step agents before the frontier labs released the same capability. Our engineering team was invited to OpenAI events for infrastructure they had already built. Being early is where the work starts, not where it ends.
When new releases emerge, someone has to absorb them, reconcile them with what's already running in production, and keep every downstream workflow stable through the change. None of that is a one-time project. It’s the standing cost of staying on the frontier, and it reemerges every time the model layer moves. A firm that builds its own platform signs up for that same recurring cost, and every hour spent carrying it is an hour not spent on client work.
The second below the line is governance and standardization. Claude Cowork accounts and a library of skill files give individuals leverage. They don't give leadership observability into how hundreds of consultants are actually using AI, whether the work is consistent from one client to the next, or whether the firm's institutional IP is being preserved or quietly evaporating into individual prompts. Governance over how the work happens, including sanctioned capabilities, top-down templates, and visibility into which workflows are running where, is what separates a tool from an operating system.
The clearest evidence is what happens at firms that already have universal access to frontier models. A major enterprise software company gave Claude Enterprise to every employee. Their entire professional services team still buys Auctor because their executives need the governance layer that ad hoc skill files don't provide. Universal access to a frontier model isn't the same thing as a firm-level operating system, and the leaders running these organizations are the first to feel the difference.
The third is the deepest, and it’s the one a demo never shows. It’s the enterprise-grade software the platform needs to be safe to run on real client work. Workflow orchestration and the business process logic the work actually runs on. SLA enforcement and the audit trails that prove what happened. Controlling who can see and do what, across both the firm's people and the client's. Prompt injection defenses. Compliance baselines like SOC 2, GDPR, and HIPAA, held steady as the platform changes underneath them.
A build that stops at the waterline works in the demo and fails in production. The part that holds up under a real client engagement is everything below the line, and it’s the part no one counts when an SI asks what it would cost to build its own.
It’s also the part the budget misses. The build-versus-buy spreadsheet usually carries two lines, what a license costs and what a small internal team costs. The real comparison has much more than that.
A standing team pulled off billable client work. Infrastructure and hosting. Compute and token spend that grows with every consultant who uses the platform. The recurring cost of keeping all of it current as the model layer moves, which never goes to zero. Each line is a cost the original model didn't carry, and together they’re why the builds we watch come in higher than the projection that justified them, at a lower quality standard than the firm could’ve simply bought from the outset.

A firm best positioned to build internally is one of Auctor's customers, a recent Anthropic partner thatdeploys Anthropic for a living. If anyone could build their own version of an SI operating system on top of frontier models, it was them.
In our first conversation with their CEO, the framing was we're tinkering. When we caught up with the same person deeper into the build, the framing had shifted. People are doing everything. There's no standards.
The firm that should have been most capable to build their own version discovered the cost wasn't in the building. It was in the maintenance. Tinkering produces capability. It does not produce coherence. The pattern we keep seeing at firms with deep AI expertise but no purpose-built infrastructure is the same: 200 consultants doing 200 versions of the work. The tooling exists, but the system doesn't.
The cost of building shows up as standards drift, IP fragmentation, and the absence of a top-down forcing function, not as engineering salaries. Those costs compound monthly and only become visible when leadership tries to enforce consistency and discovers there's nothing to enforce against.
There comes a point where the build is no longer a decision the leadership team gets to revisit cleanly. Consultants have been trained on the homegrown tooling. Engagements are running against it, and the technical consultants and solution architects who built it are now maintaining it instead of serving clients.
Every hour they spend keeping the internal build alive is an hour not spent on the change-management work clients actually pay for. Walking away means writing off the investment, retraining the workforce, and explaining to the board why a strategic bet didn't survive contact with the work.
The firm is locked in before it knows it's locked in, and the path forward is to keep building. Not because the build is working, but because stopping is more expensive than continuing.
Buying flips every one of the three commitments onto someone else's roadmap. What buying results in is the technical function the firm isn't going to build itself, a platform pushed to stay ahead of the frontier as the models change, rebuilt to take advantage of new capabilities the moment they ship, with the compliance baseline and the governance layer maintained underneath it.
Together, these are what keeps the platform a firm depends on in 2026 still working in 2028 and beyond.
Buying also brings expertise the firm can't easily hire for. Auctor's deployment team has run this transformation before, and they configure the platform to how the firm actually delivers, building out its specific workflows during rollout rather than handing over a blank tool to figure out.
The larger effect is the platform becomes the conduit for changing how the firm works, not another tool layered on top of how it already works. The firm's processes evolve around it. Once Auctor is in place, the questions stop being about features and start being about the business, how the firm prices its engagements, how it goes to market, how it sells itself in a category where implementation is becoming commoditized. That’s the transformation that can’t be bought off a feature list.
The effect closer to the ground is what the firm gets to keep doing. At the firms we work with, conversations with their best clients stay about the work, the implementation, the methodology, and the outcomes. A firm busy maintaining its own platform ends up talking to clients about its tooling instead. A firm that buys one doesn't.
The build-versus-buy decision in 2026 will define what the firm becomes in the near future. The numbers don't see it.
An SI that builds its own AI platform is choosing to become a software company that also does services. The engineering function stops being a project staffing problem and becomes a permanent product team. The roadmap stops being client deliverables and becomes platform releases. The benchmark stops being other SIs and becomes the software vendors setting the pace it now has to match. The firm has signed up for a fight it isn't structurally built to win, against opponents better resourced and more focused.
An SI that buys its platform is choosing to stay in the services business. The firm's outcomes stay on client work. Staying ahead of the frontier and holding the compliance baseline are someone else's problem to carry. The firm spends valuable time getting better at what it set out to be the best at: the institutional knowledge, the client relationships, the methodology that's specific to how it delivers.

Most firms running this evaluation tell themselves they're choosing between two versions of the same future. They're choosing between two different firms entirely.
One path ends with the firm being a software company on the side. The other ends with it becoming the best SI in the category.
Auctor is the AI-native system of action for software implementations. Systems integrators and ISV professional services teams run the full lifecycle on a single platform, from pre-sales through go-live. Auctor is backed by Sequoia Capital and partners with the leading implementation firms in the OneStream, Salesforce, ServiceNow, and broader enterprise software ecosystems.