Budget season, watch out for the promise of "build it with AI"

It's budget season at most companies, and you've probably already heard this line in a meeting: "we can build this system in-house, it's cheaper with AI." The proposal sounds obvious. The problem is they're not always calculating the right cost.

With the rise of AI, it's become common to use Vibe Coding to build systems quickly, without going through a formal software engineering process. And that's exactly where the risk I want to flag in this article lives.

The risk of swapping SaaS for software built with Vibe Coding

Vibe Coding solves a specific problem: speed. AI builds code fast, but code is just one part of building software. Process is what organizes things, defines requirements, architecture, layers of responsibility, automated testing, version control and configuration management.

Without process, you don't have a system. You have a prototype that works today and that hardly anyone can explain tomorrow.

The biggest cost isn't building, it's maintaining

I've worked on building and maintaining systems for over 16 years, and I can tell you: this is the point that weighs the most on the decision and comes up the least in the budget conversation. Most of the effort and money in software isn't spent building it, it's spent maintaining it over the years.

When leadership considers swapping a SaaS for an in-house system, they usually compare the current subscription cost against the cost of building it. That math is incomplete. What's missing is the question: how much does it cost to maintain this new software? Who's going to fix bugs, update dependencies, adapt it to changing systems, train whoever joins later? As I've already talked about who pays, who buys and who maintains a system, each of these audiences runs a different math, and the one who ends up footing the bill for poorly calculated maintenance is always the team that was left out of that decision.

Without a well-defined development process from the start, maintaining it becomes more expensive than what's imagined in the budget.

Cloning the current system doesn't solve the problem

Another common mistake in this decision is treating the project as a copy. The company, in practice, wants to duplicate the SaaS it already uses, including features it never actually used and that were designed for a different reality (selling to as many customers as possible), a different company, a different context.

That's not building a new system. It's replicating someone else's intellectual property and bringing home the same problems the current system already had, like requirements and features that add little value. The goal should be different: thinking about what this new software needs to be for your company's specific reality, not what the SaaS vendor decided to build. It's basically questioning the specifications before copying it outright.

The path that works: process, not just code

Building on a solid model is what lets you maintain and evolve the system for years, because most of the work is in maintenance, not in building it.

That doesn't mean giving up on AI. It means using it within a process. AI agents step in to expand the software engineer's capacity, and they operate within a flow that combines AI's speed with process control. Frameworks organize the work of these agents within the development flow. And context, the files, the rules, the people involved, is what keeps these agents up to date and aligned with the company's reality.

I believe that combination, process plus AI, is what sustains a system long term. Vibe Coding alone, without process, delivers speed in any direction. I say this from my own experience: I tried to sustain a system built with no foundation for 3 months, and the result was obvious, scrap it and start the right way.

The question left before approving the budget

Before you cancel that SaaS thinking you'll save money, ask the team this question: are we removing a cost on one side, but what cost are we creating on the other? How much does it cost to maintain this new software, and what do we need to have in place, architecture, version control, configuration, process, to sustain that maintenance for the coming years? And if that technology leaves the company? What can be done? What's the risk of this move for the business?

If that answer doesn't exist before the budget gets approved, the problem isn't the technology. It's the decision.

Take care! Leandro | PMP | Project Manager and PMO