AI Made Building Cheap. Ownership Is Still Expensive.

I am tempted to build my own weight-loss app

I need to lose weight. I know the boring parts: eat less, move more, stay honest for long enough that the numbers move.

I could pay ten euros a month for an app that tracks it. Instead, I keep thinking about building a small one myself.

Not because it would save ten euros. It would not. I would build it because I enjoy making things. Because I could make the screen fit exactly how I think: one place for weight, a simple food log, a weekly view that does not try to turn breakfast into a personality test. I could have it working in a weekend.

Most importantly, the risk of failure is almost zero. If it breaks, I write my meals in Notes for a week. If I stop maintaining it, nothing important stops. No customer waits. Nobody misses payroll. There is no security review, no onboarding, no quarter-end report that depends on it.

That is a good reason to build something.

It is not the reason a company should build its own operating software.

“Couldn’t we just build a small CRM?”

A client asked me this recently. They did not want Salesforce. They did not need every feature in HubSpot. They needed contacts, deals, reminders, a few reports and some automation. “Couldn’t we just build a small CRM ourselves?”

The honest answer is: yes, probably. A competent person with good tools can build a respectable first version quickly now. AI has changed that calculation. A screen that once took days can take hours. A workflow that needed a developer can start as a prompt, a database and a few integrations.

That is real progress. I use it every day.

But the question is not whether you can build version one. The question is what you have agreed to own once version one is useful enough that people rely on it.

Those are different questions. The second one is usually the expensive one.

AI changed the cost of starting, not the cost of owning

AI has lowered the price of making software. It has not removed the work that begins when software enters the company.

A tool that only you use can remain a useful sketch. The moment five people use it to run part of the business, it becomes a system. Someone needs the right access. Someone needs to understand what happens when an automation misfires. Someone needs to explain why a number changed. Someone needs to decide what the tool does when the real world refuses to fit the happy path.

Then the requests begin. Can we add this field? Can it work for Spain too? Why did this record duplicate? Can finance see this but not edit it? Why did the customer not receive the email? Can it connect to the new quoting tool? Can the new sales hire get trained before Monday?

None of those questions are evidence that the tool was badly built. They are what happens when a useful tool meets a real company.

Software vendors employ product managers, support teams, security people, implementation specialists and engineers because these questions keep arriving. You do not escape that work by deciding to own the tool. You simply bring it inside.

The invoice is rarely the biggest cost

Internal software has obvious costs: maintenance, bugs, security, permissions, documentation, integrations, migrations, onboarding, product evolution, support, and ownership when the person who built it leaves.

Most teams remember those in theory. They still underestimate them because the first version looks so clean. The builder knows the shortcuts. The data is still simple. Nobody has asked for an exception yet.

Then a salesperson changes territory. A customer has two legal entities. Someone needs a report that compares this quarter with the last one. A new data source arrives. A privacy request lands. The original builder is on holiday, busy, or gone.

The invoice is not always dramatic. It arrives in fragments: ten minutes here, a Friday afternoon there, a meeting that should have been about customers and becomes a discussion about permissions. That is why it is easy to miss.

The biggest cost is often not development cost. It is management and team attention.

When the sales system becomes the project

This matters most in commercial teams because sales tools are unusually good at creating the feeling of progress.

A company can spend weeks improving CRM structure, automation, dashboards, lead scoring, data cleaning and internal workflows. Every task is concrete. Every task produces something visible. A cleaner pipeline is satisfying in the same way a newly organised desk is satisfying.

Meanwhile, the harder work remains where it was. Customers are not called. Stalled deals are not examined. Qualification stays vague. Managers do not coach. Forecast meetings discuss the number instead of the deal. Nobody learns why opportunities are not progressing.

The dashboard may become more accurate about a process that is still weak.

I have seen teams blame a CRM for problems that were really commercial decisions nobody had made. The stages were unclear because nobody agreed what qualified meant. The forecast was wrong because reps had no reason to say a deal was slipping. Follow-up was inconsistent because nobody owned the next step, not because there was no field for it.

Sometimes the CRM really is bad. Sometimes replacing it or customizing it is exactly right. A tool can make good work easier and bad work harder to hide.

But tools should solve a clearly identified commercial problem. They should not become the project because rebuilding them feels more tractable than confronting the problem.

The biggest cost of building your own sales tools is often what the team stops doing while building them.

Build for a specific edge, not because the default is irritating

There are good reasons to build internal software. Your process may be genuinely unusual. The tool may sit at the centre of a proprietary service. It may let you deliver something competitors cannot copy. A mature product may solve only half the need and force the other half into manual work every day.

In those cases, building can be the cheaper decision precisely because it removes a real operating constraint.

But irritation is not the same as strategic difference. Every mature SaaS product has parts that are clumsy, overbuilt or designed for someone else. That is the price of buying a product that has survived thousands of companies with different habits.

If a product solves eighty percent of the need, the remaining twenty percent may be a training issue, a configuration decision or a process worth simplifying. It may also be the part that matters most. The point is to know which one it is before you start building.

Five questions before you open the editor

You do not need a matrix for this. Ask five plain questions.

Is this strategically differentiating? Would owning this capability change what customers buy from us, or are we rebuilding a standard function because the current tool annoys us?

What happens if it fails? If it is wrong for a day, can the team work around it? Or does it interrupt sales, billing, access, compliance or customer service?

Is there already a mature product that solves eighty percent? Not a product that demos well. One that your people can actually use, with support and integrations that already exist.

Who owns it six months from now? Name the person, the budget and the time. “The person who built it” is not an ownership model.

What important work are we not doing while we build it? Be specific. Which customers will not be spoken to? Which deals will not be reviewed? Which managers will not be coached? Which decision will wait?

The last question is the one I would ask first. Building can feel like motion while it quietly moves the company away from the work that makes it money.

Keep the tool in its place

I will probably build the weight-loss app. It is a small bet, close to me, and enjoyable. If it turns into a mess, I can delete it without calling anyone.

A company CRM is not that. Neither is the quoting workflow, the customer database, the finance stack or the tool that decides who gets followed up next.

AI makes it easier to build all of them. It does not make their ownership disappear. Fun to build does not mean smart to own forever.

If your team stopped improving its internal tools for one month, what customer problem would they finally have time to solve?