Not subscribed? Sign up to get it in your inbox every week.

I surveyed a bunch of senior ops leaders last month about how they're thinking about their software stack after AI. The responses split cleanly into two camps. One was leaning into building things internally for the first time in their careers. The other was consolidating onto fewer vendors and buying more aggressively.

For the last decade and a half of SaaS, the rule of thumb that worked for almost every operator was: don't build internal tools. The build path was a quiet form of bankruptcy. Engineering was the most expensive resource in the building, every internal tool became a quarter of maintenance you didn't budget for, and the SaaS vendor down the road had a hundred engineers doing what your one engineer would attempt to ship in a sprint. Buy was the default, and the only real question was which vendor.

A specific kind of build is suddenly cheap. A small team with a strong AI workflow can scaffold a useful internal tool, end to end, in days instead of months. The ratio between what your team can ship and what a SaaS vendor can ship has narrowed, and for narrow internal use cases (the ones vendors won't bother customizing for your business), the gap has effectively closed.

But cheap to build is not the same as cheap to own. The COO with five tools and two new engineers is the cautionary tale: building is now within reach for ops teams in a way it wasn't, and a meaningful number of them are going to mistake "we can build this" for "we should own this." Most of the cost lives in the upkeep.

So the question worth putting on your stack-planning agenda this quarter has three parts: which things you build, which things you buy, and what kind of platform you build them on.

The cleanest version of this I've heard from other operators is: build the intelligence, buy the infrastructure. That maps almost exactly onto the heuristic I keep coming back to when ops leaders walk me through their stack.

Build the things that encode how your company thinks. Your specific workflow for qualifying a lead, the renewal motion your CS team runs when a customer goes quiet, the custom context your agents need to be genuinely useful for your business, the internal review process for a particular kind of contract. None of this is going to ship as a feature in a SaaS product, because no SaaS product has a market of one. These are the use cases where you have the domain knowledge and the vendor doesn't, and the work of writing it down once for a model to execute is the work that pays you back for years.

Buy the things that have a maintenance treadmill. The canonical example is integrations. You can ship a workflow that touches Salesforce, Gong, Snowflake, and your billing system in a week. But every one of those vendors is going to ship API changes, deprecations, auth migrations, and rate-limit shifts on their own schedule, forever. The team that built it in a week is the team that owns it for the rest of the product's life. The maintenance bill compounds.

The same logic applies to anything with regulatory churn, security review surface area, or a long tail of edge cases your business will never see but a vendor's other customers absolutely will. Compliance, payments infra, identity, deliverability. These are categories where someone else's engineering team is going to do a better job than yours, because their entire company depends on doing it well. Your job is to plug into them and stay out of the underlying maintenance.

The trap that catches the build-everything crowd is mistaking "I can ship this" for "I can own this." The version you ship in a week is not the version you maintain for two years.

The choice worth making is which platform you build on, because every internal tool you ship needs a place to live.

A platform here means: the layer your internal teams build custom, horizontal use cases on. The layer you maintain once so the tools don't have to be maintained one at a time. Without one, every internal tool becomes its own small ecosystem with its own deployment, its own auth, its own logs, its own failure modes. That is how you wake up with five tools and two engineers whose job is keeping the lights on.

There are roughly three tiers of platform on offer today, and the right tier for your company is mostly a function of your stage and how much engineering you have to spend.

Tier one is the bare-metal platform. This is what Stripe, Ramp, and a handful of other technically deep companies have done internally. They have built their own platform layer, with their own agent orchestration, their own data model, their own UI primitives, and an engineering team that maintains all of it as a product. The benefit is total control over performance, security, and roadmap. The cost is real and ongoing: at least a small platform team whose sole job is making the rest of the company productive on the platform. If you are not at the scale where that team pays for itself in downstream leverage, this tier will eat you.

Tier two is the composable platform. Tools like Bolt.new sit here, along with a growing list of similar products. They let a technically literate team define their own data models, write their own business logic, and ship something that feels custom, but they take the bare-metal infrastructure off your hands. The database, auth, and runtime stay theirs to operate. A mid-market company with a couple of strong engineers and an ops team that can spec what it wants can ship a real portfolio of internal tools on a tier-two platform, and the maintenance footprint is bounded.

Tier three is the horizontal no-code platform. Gumloop is the cleanest example. The whole pitch is that a non-engineer on the ops team can wire up a useful workflow, an agent, or an internal app without writing code. The trade-off is the same one the no-code world has always had: less control, less custom logic, a ceiling on complexity. For a small or non-technical team, that ceiling is high enough that you can solve most of what you'd otherwise be paying point-solution SaaS to solve, and the team that builds it is the team that owns it without needing engineering on call.

Pick the tier honestly. The most common mistake I see is mid-market ops teams who pick tier one because it feels prestigious and end up at tier two's cost with tier three's output. The second most common mistake is small teams who pick tier three and then try to push it past its ceiling for a workflow that really wanted a custom build. Right-sizing the platform matters more than which specific vendor you pick within a tier.

If you want to put one thing on next week's ops agenda, run this exercise on your current stack.

Pull your top ten line items by spend. For each one, ask three questions. First, does this vendor maintain something we genuinely cannot maintain ourselves (integrations, compliance, infrastructure, deliverability)? If yes, the renewal is probably right. Second, is the value of this vendor mostly the custom workflow we've configured on top of generic features? If yes, that workflow is a candidate to lift onto a platform you control. Third, are we using more than half of what we're paying for? If no, you are subsidizing a vendor's roadmap that doesn't serve you.

Now do the same exercise on the internal tools you've already built. For each one, ask whether the maintenance is on a treadmill (integrations, regulatory drift, security surface area) or whether it's stable code that encodes a workflow. If you have things on a treadmill that you built yourselves, those are buy candidates, even though buying back something you built feels like a loss.

The output is a short list of moves to make this quarter: renewals to kill, builds to schedule on whichever platform tier fits you, internal tools to retire in favor of vendors who will maintain them better than you can.