For most of my career, the build-vs-buy decision in IT has been a two-option conversation. You buy a vendor solution and accept the constraints that come with it, or you build something in-house and accept the development cost and ongoing maintenance burden. The decision usually came down to a calculation about cost, control, and capability, how much custom logic do you need, how much can you afford to develop and maintain, and how badly does the vendor's product map to your actual workflow.
For a mid-market organization, call it 250 to 1,000 employees (the size of most regional businesses and most non-flagship higher ed institutions), the calculation almost always landed on buy. Building was theoretically possible but operationally indefensible: you didn't have the developer headcount, nor did you have the maintenance bandwidth. The opportunity cost of putting your two or three competent engineers on a custom build was a project that would never happen and a system that would, in five years, become someone else's problem to maintain after the original builders left. So...you bought. Sometimes you got a product that fit. Sometimes you spent the next few years living with or configuring around the gaps because your use case didn't fit neatly into the product. This trade-off was worth it because the productivity gains outweighed the losses or technical debt that was accumulated to work around those gaps.
This calculation has changed. Mid-market IT leaders who are still defaulting to buy without seriously considering the alternative are working from a model that no longer reflects what's actually possible.
The change is that AI coding tools have made a specific category of custom development cheap enough, fast enough, and tractable enough that the build option becomes defensible for organizations that previously couldn't justify it. Not for every problem. Not for the deep, complex, infrastructure-level work that still requires senior engineers and long timelines. But for the specific kind of build that mid-market organizations actually need, the integration, the workflow tool, the small custom application that sits between two vendor products and makes them work the way the institution actually works. AI coding tools change the math in a way that's worth taking seriously.
This is a post about how that calculation has shifted and what the new decision logic looks like.
The classic build-vs-buy decision rested on three rough estimates. How much would it cost to build the thing the organization needed. How much would it cost to buy a product that mostly did what was needed. And how much would the ongoing maintenance cost be in either direction. The math was almost always uglier on the build side, because development is expensive, software estimates are notoriously optimistic, and the people who could build the thing were almost always the same people the organization needed to keep the existing systems running.
The vendor side, by contrast, had a clean monthly number. SaaS pricing made buy decisions easy to defend in budget conversations. The product existed. It had a roadmap. It had support. The implementation cost was bounded. The maintenance burden was off your team. Even when the product was a poor fit, the path of least resistance was to buy and adapt the workflow to the product. Most mid-market organizations spent the last decade making this trade-off thousands of times, accumulating a stack of vendor products that mostly fit and a workflow that mostly adapted around the gaps.
The build-with-AI option introduces a third path that didn't exist five years ago in any practical sense. The path is: develop the specific thing you actually need, on the timeline of weeks rather than quarters, with a small fraction of the engineering effort the same build would have required. The development cost drops because AI coding tools handle the boilerplate, the patterns, and a significant portion of the implementation. The senior engineer's role shifts from writing code to specifying behavior, reviewing AI-generated code, and integrating the output into a coherent system. The result, when it works, is a custom application that fits the organization's actual workflow rather than a vendor product that approximates it.
The key phrase there is "when it works".
The argument I'd make is not that AI coding tools have made building universally cheaper than buying. The vendor option still has real advantages: external maintenance, defined support contracts, integrations the vendor handles, compliance certifications that come pre-packaged, risk transference, and a roadmap that's funded by someone else's revenue. Those advantages are not erased by the existence of AI coding tools, and any post that argued they were would be wrong.
The argument is narrower. There exists, in every mid-market organization I've ever worked with, a category of need that the vendor market doesn't serve well. The specific integration between Vendor A and Vendor B that neither one cares enough to build natively. The reporting layer that pulls from four systems and produces the one view someone actually wants. The workflow tool that automates the institutional process that exists in your organization and nowhere else. The portal that gives constituents a specific kind of self-service that doesn't fit any vendor's product roadmap. These are the gaps in your current stack, the places where the workflow has adapted to the vendor product rather than the other way around.
The classic build-vs-buy calculation treated these gaps as inevitable. You couldn't afford to build a solution for them, and no vendor was going to build it for you either, so you adapted the workflow and lived with the inefficiency. Most mid-market organizations have dozens of these adaptations layered into their operations, each one small enough to be tolerable individually and significant enough in aggregate to consume real organizational capacity.
The build-with-AI path makes these gaps addressable. Not all of them. Not effortlessly. But many of them, on timelines and budgets that previously made no sense. A two-week project that produces a working integration is a different proposition than a six-month project that produces the same integration. The vendor calculation has to be re-run when the alternative is no longer "build it ourselves over six months" but "build it ourselves over six weeks."
There is, in my mind, one specific case where this calculation shifts most aggressively: the SSO tax. The pattern, for anyone who hasn't run into it directly, is that major SaaS vendors charge significantly more for plans that include SAML/SSO integration (or worse, SAML/SSO/LDAP integration). The base tier of the product works fine and meets most of the organization's functional needs. SSO is gated behind the enterprise tier, often at two to five times the per-seat cost. The functional difference between the two tiers, for many organizations, is just SSO. The price difference is sometimes the entire defensible budget for the tool. It's so bad that there are websites dedicated to exposing companies who do this as a practice – https://www.sso.tax.
The SSO tax is a textbook case of vendor pricing that doesn't reflect underlying cost. SSO is genuinely cheap to provide; it's gated because vendors have determined that organizations large enough to require it can also afford to pay for it. This has been a structural inefficiency in the mid-market vendor stack for years, and most IT leaders have grudgingly absorbed it, because the alternative, building their own SSO-integrated equivalent, was out of reach.
It is, increasingly, no longer out of reach. A small custom workflow tool with proper SSO integration, built with AI assistance, can be cheaper in total cost of ownership than paying the SSO tax on the equivalent vendor product for a hundred-plus-seat deployment. The build is not zero-effort, the caveats from later in this post still apply, but the math has crossed a threshold for a category of tooling that used to be vendor-default. Workflow tools, form builders, internal portals, lightweight ticketing systems, niche reporting frontends: the entire mid-tier of the SaaS market is being quietly reassessed by IT leaders who have noticed that paying the SSO tax on a tool that doesn't quite fit their workflow is no longer the best option available.
This is not to say every SSO-taxed tool should be replaced with a custom build. The vendor's other advantages still matter. But the obviation pressure on vendors who have priced themselves through the SSO tax is real and growing, and the leaders running these calculations should know that the leverage in the conversation has shifted.
The honest version of this argument requires acknowledging what build-with-AI doesn't change.
It doesn't change the long-term maintenance burden. The code you write with AI assistance is still code your team will need to maintain, debug, extend, and eventually replace. The fact that it was cheap to produce doesn't make it cheap to operate. Organizations that build with AI and then treat the resulting systems as zero-cost will discover, two years in, that they have the same maintenance burden as if they'd written the code themselves, plus the additional complication that the original author may not remember exactly how the AI-generated portions work.
This is, in a real sense, the load-bearing problem translated into code. The senior engineer who built a custom integration with AI assistance now holds the context for how it works, why it's structured the way it is, what edge cases it handles, and what would break if you changed it. The fact that an AI helped write the first draft does not distribute that context across the team, it concentrates it in whoever sat at the keyboard during the build. The resulting system is a knowledge-concentration risk dressed up as a build efficiency. Mid-market organizations that build with AI without thinking deliberately about how that knowledge gets distributed are setting themselves up to discover, when the engineer leaves, that the cheap build was actually expensive in a form they hadn't accounted for.
It doesn't change the integration problem. A custom-built application that sits between two vendor products has to talk to both of those products, and the contracts those vendors offer for that interaction are sometimes generous and sometimes hostile. If a vendor changes their API on a quarterly basis, your AI-built integration becomes a quarterly maintenance project. The build-with-AI path doesn't insulate you from the vendor's roadmap decisions. It just changes the rate at which you can respond to them.
It doesn't change the requirement for someone on your team to actually understand what was built. The senior engineer who reviews AI-generated code and integrates it into a working system is doing real engineering work, and the value of the AI tool is multiplied by their judgment. An organization that uses AI coding tools without competent engineering oversight will produce systems that work right up until they don't, and then will struggle to diagnose what went wrong. The tool doesn't replace the engineer. It changes what the engineer's time is spent on.
These caveats matter because the enthusiasm around AI coding tools tends to undersell the operational costs. The first-draft cost drops dramatically. The total cost of ownership drops less. Mid-market leaders evaluating build-with-AI options should be running the math on year-five operating cost, not just year-one build cost, and the math is genuinely better than the alternative in many cases but not in all.
The decision logic I'd offer is roughly the following.
For commodity functions where a vendor product exists, is well-maintained, and is roughly priced to your scale, buy. The vendor's advantages, external maintenance, compliance, support, roadmap, outweigh the loss of fit. Identity management, payroll, accounting, basic CRM, learning management, donor management at small scale: this is the buy column for most mid-market organizations and probably should stay that way.
For specialized functions where the vendor market has produced products that all approximate what you need but none of them fit, examine the build-with-AI path seriously before defaulting to the least-bad vendor. The gap between "almost what we need" and "exactly what we need" used to be unaffordable. It often isn't anymore. The right question is no longer "which vendor is closest to what we want" but "is the gap small enough to live with, or is it large enough to justify building the specific thing." The second question used to be rhetorical. It isn't now.
For glue between systems, build-with-AI is almost always the right call. The integrations that connect your vendor products to each other, the reporting layers that aggregate across systems, the workflow tools that move data between platforms, these are the cases where the vendor market is least helpful, the customization is most valuable, and the build-with-AI path is most viable. Mid-market organizations that have been paying integration vendors significant amounts of money to glue together systems they already own are probably the largest population of customers whose math has changed.
For deep, foundational work, the systems your organization will operate for the next decade, the work that requires senior engineering judgment from end to end, be cautious with the build-with-AI path. The tools are real and useful, but the longer the system's lifespan and the more critical its operation, the more the quality of the engineering matters and the less the AI's productivity gains compensate for any reduction in engineering rigor. This is not a place where the time savings should change the decision.
The underlying point is that the build-vs-buy decision used to be a two-option choice with a default toward buy, and it has quietly become a three-option choice with a more interesting default. The default is no longer to buy by reflex. It is to ask what kind of need you're trying to meet and which of the three paths is best suited to it.
Mid-market IT leaders who haven't updated their decision-making to reflect this are leaving a meaningful amount of value on the table. The vendor-product approach that was correct for most needs five years ago is correct for fewer needs now, and the path that was uneconomical five years ago is economical for a growing share of what mid-market organizations actually need.
The discipline is not to swing the other way. Building with AI is not always the right call, and organizations that get excited about the new capability and start building everything they can will discover the operational debt this post has tried to be honest about. The discipline is to evaluate each need on its merits, with the three options actually on the table, and to choose the path that fits the work rather than the path that fits the habit.
The habit, for most mid-market IT shops, is to buy. That habit was correct for a long time. It is now, in a significant share of cases, costing organizations the chance to actually fit their tools to their work.
— Chris