Build vs Buy Internal Tools: The Cost of Replacing SaaS With AI

This week, GPT 5.6 has been a workhorse for implementing UI when I give it examples and constraints. It can take a reference, follow the existing design, and produce a credible result quickly.

That makes replacing software-as-a-service (SaaS) products increasingly tempting. If your team uses a small part of Trello, Linear, or another large product, why keep paying for every seat when an agent can build the specific workflow you need?

The calculation often compares the subscription with the hours required to generate a working replacement. It looks sensible because the application on screen is the most visible part of the work. Once colleagues start depending on it, the company also owns its users, data, permissions, integrations, failures, feature requests, and eventual replacement.

Before replacing SaaS with an AI-built internal tool, I would compare the subscription with the complete cost of ownership. I would also ask whether maintaining this software is a useful place for the company to spend its attention.

AI changes the initial build cost

AI can reduce the cost of testing whether an internal tool is useful. Forms, tables, dashboards, and focused integrations can be implemented much faster when the requirements and constraints are clear.

That is valuable. A working prototype can reveal a bad assumption before the team commits to a larger project. It can also demonstrate a workflow more clearly than a document or meeting. Sometimes the prototype is all you need to learn that the existing SaaS product is good enough.

I use agents for this kind of exploration, but I still want a human engineer responsible for the system that reaches production. I wrote more about that distinction in Agentic Engineering Is Not About Writing More Code.

The ownership problem begins when a useful prototype becomes a team application without a deliberate production decision. Someone shares the URL, a few colleagues add real data, and the tool quietly becomes part of the business.

AI has changed how quickly the company can reach that point. It has not removed the operating work that follows.

Compare the subscription with the full ownership cost

A monthly subscription is easy to see. Internal engineering work is distributed across salaries, interruptions, hosting accounts, and small fixes, so it often disappears from the comparison.

A more useful calculation looks something like this:

124-month ownership cost =
2  (build hours
3  + expansion hours
4  + maintenance hours
5  + support hours)
6  × value of an hour
7  + infrastructure
8  + incident recovery
9  + eventual migration

This will not produce a perfectly accurate number. It does force the team to include costs that an afternoon prototype leaves out.

What is your time worth?

If a founder builds an internal tool over a weekend, the accounting cost may appear close to zero. The weekend still had other possible uses.

The relevant concept is opportunity cost: the value of the best work you did not do because you chose this work instead. For a founder, that could be speaking to customers, improving the product, or closing a sale. For an engineer, it could be fixing a customer-facing reliability problem or shipping a feature tied to revenue.

An hourly consulting rate is not always the right measure. The useful question is more direct: what valuable work will these hours replace?

That question should also be asked about maintenance. Ten hours spent building a custom project tracker may be reasonable. Ten hours every few months spent changing its workflow, helping users, and fixing integrations can alter the decision quickly.

Calculate beyond the first month

The first implementation usually reflects the current workflow and its first group of users. Both change.

A reasonable ownership estimate should include:

• How often the workflow changes
• Which external APIs or data sources it depends on
• How many people will need access
• What support those people will expect
• Whether downtime blocks important work
• How the data will be backed up and exported
• Who will update dependencies and investigate failures
• What happens when the original builder leaves or becomes busy

The vendor side deserves the same scrutiny. SaaS prices increase, per-seat pricing can become expensive, and a vendor may take the product in a direction that no longer fits. Buying transfers part of the operating burden; it does not guarantee a permanent price or a perfect workflow.

This is why the decision needs a time horizon. Compare both options over a year or two, include uncertainty on both sides, and avoid pretending that internal engineering time is free.

A custom task manager becomes a product when other people depend on it

Imagine building a task manager tailored to the way you work. You need a board, a few statuses, some filters, and perhaps a connection to your calendar. An agent can help produce that without recreating everything in Trello or Linear.

For one person, the result may remain small. You know what every field means, you can tolerate rough edges, and you are the support team.

Bringing other people into the tool changes its economics.

More users create more requirements

A colleague needs an invitation. A manager needs different permissions. Someone wants to know who changed a task. Another person expects notifications, search, imports, exports, or a usable mobile layout.

Authentication identifies the user. Authorisation determines what that user may see and change. Those concerns become important when an internal tool contains financial, employee, operational, or customer data. The OWASP Top 10 for 2025 includes broken access control, security misconfiguration, and software supply-chain failures among its major application-security risks.

An internal label does not remove those risks. Someone still needs to decide how access is granted, where credentials are stored, and what happens when an employee leaves.

The team may not need the complete feature set of a mature vendor. It does need the subset required to operate its chosen workflow safely. That subset often grows as more people depend on it.

Expansion creates product work

Successful internal tools attract requests because people can see ways to improve them. The finance team needs another report. Operations wants a new status. A manager asks for approval rules. A vendor changes its API.

Each request may be small, but someone must understand it, decide whether it belongs, implement it, test it, and support the result. The company has taken on a modest product-management job alongside the engineering work.

Strict scope can keep an internal tool inexpensive. A stable workflow with a small number of users may need very little maintenance. That is a genuine argument for building.

The difficulty is preserving that scope when the tool becomes useful. If the team cannot say no to expansion, the original comparison with a SaaS subscription stops being relevant.

Every replacement expands the internal software estate

One custom application may be easy for a lean team to absorb. Replacing project management, finance reporting, support operations, and approval software creates four separate ownership commitments.

Each application can add:

• A deployment and hosting configuration
• Dependencies that receive security and compatibility updates
• Credentials and external integrations
• A data store and recovery requirement
• Users who need access and support
• A workflow that changes independently
• An eventual migration or retirement project

AI makes each application easier to start. That can hide the cumulative cost because no individual build looks large enough to require a broader plan.

Maintenance compounds across tools

Ten small applications are unlikely to fail or need changes on the same schedule. That sounds helpful until the team is interrupted by a different application every week.

One API changes. Another tool needs a new permission level. A dependency update breaks a build. An employee cannot find the data they need. None of these tasks is necessarily difficult, but each asks someone to stop their current work and rebuild context.

Shared infrastructure can reduce the technical repetition. A company might standardise authentication, hosting, monitoring, databases, and deployment. AI may also make routine updates cheaper.

That reduces the marginal cost of each application, but it does not remove the need to understand the workflow, choose which requests to implement, help users, or decide when the tool should be retired. A shared platform handles plumbing. It cannot own every business process built on top of it.

Count the existing estate before adding another tool

A build-versus-buy calculation should include the internal software the team already maintains.

Ask:

• How many custom internal applications are currently in production?
• Does each one have a named owner?
• How much engineering time did they require during the last few months?
• Are any of them waiting for updates because core product work takes priority?
• Would the proposed replacement rely on the same constrained people?

A tool can be economically reasonable in isolation and still be the wrong addition to an overloaded estate. The more SaaS products a company replaces, the more deliberately it needs to manage its new role as a software operator.

Non-core software needs a higher build threshold

Software can be strategically important without appearing in the customer-facing product. A distinctive operational workflow may improve delivery, protect margins, or let a company serve customers in a way competitors cannot easily copy.

But plenty of internal software is commodity infrastructure. A custom task manager, payroll system, password manager, or chat application may fit the team perfectly without helping the business compete.

That software needs a higher build threshold because every hour spent on it competes with the work the business exists to do.

Buy commodity capabilities

Buying usually makes sense when a mature product covers the important requirements and the workflow is common across many businesses.

The subscription pays for more than the visible interface. It contributes to continued development, infrastructure, security work, support, integrations, backups, and the less exciting features that become important when many people use the system.

You may dislike some features, ignore most of the navigation, and pay for capabilities you do not need. That can still be cheaper than assigning valuable internal time to an undifferentiated product.

Automate the narrow gap

Build and buy are not the only options.

Perhaps the existing product handles task management well, but somebody manually copies its data into a weekly report. Perhaps finance has a suitable system but needs information from another application. A focused automation can remove the expensive part of the workflow while leaving the larger product with the vendor.

The company still owns the integration, so it still needs an owner and a failure plan. The surface area is much smaller than an entire replacement application.

This is often the most practical use of custom software: keep the mature product and build only the part that is specific to your business.

Build the smallest workflow worth owning

Custom software becomes more compelling when the workflow is specific, recurring, and valuable enough to justify continued ownership.

I would want to see several conditions:

• Existing products cannot support the important part of the workflow without substantial compromise
• The improvement affects delivery, cost, customer value, or a genuine competitive capability
• A person or team can own the application after launch
• The expected operating cost is acceptable alongside the existing internal software estate
• The first scope can remain narrow

When those conditions hold, custom internal software can be a sensible investment. MBV Labs helps founders and lean teams evaluate these tradeoffs and build focused systems that remain understandable after launch.

A practical calculation before replacing SaaS

Before replacing a subscription, I would write down the answers to these questions:

The resulting choice can be simple:

The calculation does not need to prove that buying is always cheaper. It needs to stop the initial implementation speed from deciding the question on its own.

What I would do now

I am optimistic about AI-assisted software development. The tools are already useful for exploring ideas, producing interfaces, and testing a narrow workflow before committing substantial engineering time.

My current approach is to use that speed without quietly accepting every prototype as a permanent application. I would buy commodity capabilities, automate narrow gaps around suitable products, and build when a specific workflow creates enough value to justify its complete ownership cost.

Better agents and shared platforms may reduce maintenance over time. I would welcome that. Until the operating work has actually disappeared, I would keep it in the budget.

If your team is considering replacing SaaS or turning a manual process into an internal tool, tell me about the workflow. I can help determine whether the smallest useful answer is buying, automating, or building.