Your Portfolio Is Paying for SaaS It Could Build in Weeks

Key Takeaways

• SaaS is the least-examined line in most portfolio companies. It renews on autopay, it is spread across teams, and nobody owns the whole list.
• The cost to build fell, and the spreadsheet didn't notice. A third of the builders in one 2026 survey have already replaced at least one SaaS tool with something they built.
• Workflow tools go first. If a subscription mostly encodes how your team moves work from step to step, it is the best candidate for a custom build.
• Build where you differentiate, buy where you don't. Payroll, accounting and security are the same at every company. Your quoting flow is not.
• DIY builds fail more often than bought tools. The fix is ownership and a partner who ships, since a build nobody maintains is just a new kind of shelfware.

A third of software builders have already pulled out at least one SaaS tool and replaced it with something they built themselves. Retool's 2026 build vs. buy report found that 35% of teams have replaced functionality of at least one SaaS tool, and 78% plan to build more custom tools this year. (Worth saying up front: Retool surveyed 817 of its own customers and builders, so this is a crowd that already likes building. I still think the direction is right.)

Now put that next to what companies are spending. Zylo's 2026 SaaS Management Index puts median SaaS spend at $9,455 per employee, and says organizations leave an average of 36% of their SaaS licenses unused.

Run that on an illustrative 300-person portfolio company and you get a seven-figure software line, and roughly a third of the seats inside it are doing nothing.

I don't think most operating partners have looked at that line through a build lens yet. They look at it through a procurement lens. Negotiate the renewal. Consolidate two tools into one. Push back on the price increase. All useful. But the question has changed. For a growing slice of that list, the real question is whether the company should be paying for the tool at all, or building the narrow piece it actually uses.

That is what this post is about. Some of your SaaS should be rebuilt. A lot of it shouldn't. The skill is telling the two apart.

The SaaS Line Is the Least-Examined Cost in the Portfolio

Headcount gets a monthly review. Cloud spend has a FinOps team. SaaS sits in between and mostly renews itself.

The reason is structural. SaaS gets bought one team at a time. Sales buys a sales tool, ops buys a workflow tool, finance buys a reporting tool, and each one looks small on its own. Nobody sees the full list until a diligence team or a new CFO pulls it together. By then, the tools are wired into how people work, and cancelling anything feels risky.

In a PE context this matters more than usual. You have a hold period. Every dollar of recurring cost that comes out of the business shows up in EBITDA every year until exit. And the same software patterns repeat across portfolio companies, so a fix that works in one company tends to work in the next.

Read the renewal list like a deal team would

Pull every SaaS contract into one sheet: vendor, annual cost, seats paid, seats active, renewal date, and the owner. Then add one column most companies never fill in: what does this tool actually do for us, in one sentence? You will find a surprising number of lines where that sentence describes a simple workflow wearing an expensive interface.

Build Costs Fell Before Anyone Updated the Spreadsheet

For most of the last 15 years, "build it ourselves" was the wrong answer for anything outside the core product. Custom software meant hiring engineers, a long project, and a maintenance burden that never went away. SaaS won because it turned that capex into a predictable subscription.

That trade has shifted. AI-assisted development has made it much faster to stand up a narrow internal tool: a form, a review queue, an approval flow, a dashboard on top of data you already own. Retool's report describes teams getting working prototypes in days. In my view, a well-scoped internal tool that replaces a specific subscription is now a matter of weeks of focused work rather than quarters.

This is the piece that matters most to me. A lot of SaaS is workflow logic with a login page. Someone figured out a sensible sequence of steps, encoded it into software, and charged per seat for access. When an agent or a small custom app can run that same sequence against your own data, the reason to rent it starts to fade. What stays valuable is the data, the context about your business, and the judgment about what the workflow should be.

Building still costs money. It just costs little enough now that the old default deserves a second look.

Re-price the build option at every renewal

The build estimate you got three years ago is stale. Before any meaningful renewal, ask what it would take to build the part of the tool your team actually uses. Not the whole product. Just the slice that matters. Sometimes the answer is still "much more than the subscription." Increasingly, it isn't.

Workflow Tools Are First in Line

When Retool asked which SaaS categories were at risk, workflow automations topped the list at 35%, followed by internal admin tools at 33% and BI tools at 29%. CRMs and form builders, project management, and customer support tools came in between 21% and 25%.

That ordering makes sense to me. The tools at the top are the ones closest to pure process. A workflow automation tool moves data from one place to another when something happens. An internal admin tool puts a form on top of a database. These are exactly the things a small custom build does well, and they are often the tools where a company is paying for a broad platform to use one narrow feature.

The tools further down the list hold more of their value in things that are hard to rebuild: years of integrations, a large data model, or a support organization. Those can still be candidates. They just take more work, and the payoff is less certain.

Start with the tools that encode your process

The best first build is a tool your team uses every day, that maps closely to how your company specifically works, and that annoys people. If people already route around it with spreadsheets and Slack threads, you have found it. Those workarounds are a free spec.

Build Where You Differentiate, Buy Where You Don't

Now the balance, because this is where the hype gets ahead of itself.

Most of your software should stay bought. Payroll, accounting, email, identity, endpoint security, HR systems of record. The work is the same at every company, the vendor carries a compliance and scale burden you should not take on, and a custom version would make nobody's day better. Rebuilding your general ledger is not a strategy.

The build case is strongest where the software touches the way you win. Your quoting process. Your intake flow. The way your field team logs jobs. The way your analysts pull a report that no off-the-shelf tool formats correctly. In those places, a custom tool can do the job better, fit the team's real process, and keep the data inside the company.

There is a third answer people forget: cancel it. Some lines on the list are not candidates for building or buying. They are just dead.

Here's the triage I'd run on every line:

Run every renewal through the same three-way call

Make this a standing agenda item, tied to the renewal calendar. Ninety days before a significant renewal, the owner brings the line to a short review with one of the three calls and a reason. That alone will surface more savings than any single build.

DIY Builds Fail More Often Than Bought Tools

If building were the easy answer, everyone would already be doing it. The data says the opposite.

MIT's 2025 GenAI Divide research, as reported by Fortune, found that AI tools bought from specialized vendors and built through partnerships succeed about 67% of the time, while internal builds succeed only about one-third as often. That study looked at generative AI projects broadly, not SaaS replacement specifically, so treat it as a signal rather than a forecast. But the signal is loud.

I read it two ways. First, a portfolio company with no engineering team should not try to build software on its own because a demo looked easy. Second, "build" and "do it yourself" are different decisions. In that study, partner-led builds sit on the successful side of the line. A custom tool built with people who have shipped production software before is a very different bet than a side project from someone in ops.

Budget for ownership before you write code

Every custom tool needs an owner, a support plan, and someone who fixes it when an upstream system changes. If nobody inside the company will own it, decide who outside will. A build with no owner turns into the same shelfware you were trying to cancel, except now you can't call the vendor.

Shadow Builds Are Already Happening in Your Portfolio

Here's the uncomfortable bit. Whether or not leadership has a build strategy, people are building.

The same Retool report found that 60% of builders have built something outside IT oversight in the past year. The top reasons were speed and the gaps in existing SaaS. The motive is practical: the tool they were given doesn't fit the work, and building something is now easy enough to do on a Tuesday afternoon.

That creates real risk. Customer data in unreviewed apps. Tools that break when the person who built them leaves. No access controls, no audit trail. It also tells you exactly where the demand is. Every shadow tool is a vote for what the official stack is missing.

Give builders a paved road

Ignoring shadow builds doesn't stop them, and banning them pushes them further out of sight. A better move is a short, approved path: a standard place to host internal tools, single sign-on, logging, a review step for anything that touches customer data, and a named owner. Then the best shadow tools can become real ones.

The Renewal Calendar Is Your Build Roadmap

I'm bullish on this shift. Portfolio companies have been renting generic software for jobs that are specific to them, and the cost of doing that job yourself has dropped a lot. That gives operating partners a lever they didn't have three years ago.

I don't think the end state is clear yet, though. Nobody knows exactly where the line between build and buy settles once agents can run more of these workflows on their own. Some SaaS categories will hold up better than expected. Some custom builds will turn out to cost more to maintain than anyone planned. I'd rather say that plainly than pretend the answer is "build everything."

What I'm confident about is the starting point. Pull the renewal list. Mark every line build, buy or cancel. Pick the one build where the workflow is specific, the pain is real and an owner exists, and ship that first. That is the kind of work we do through PressW's Custom AI Application Development and Forward Deployed AI Engineering teams. If you want a second set of eyes on your portfolio's renewal list, Book a Discovery Call.

FAQ