If something can go wrong, it will go wrong

Table of Contents

One of the first lessons I remember from Computer Science Engineering was Murphy's Law: If something can go wrong, it will go wrong.

At the time, it sounded like a little phrase lecturers tell students so we stop pretending the happy path is the whole system. Years later, after seeing enough software break in production, enough processes fail at the exact wrong moment, and enough "simple" tools become strangely complex, it feels less like pessimism and more like operational hygiene.

Murphy's Law teaches you that if you choose to own a system, you are also choosing to own the day it does not behave.

That matters now more than ever because the buy-versus-build question has changed.

AI changed what is buildable

A few years ago, "could we build this ourselves?" was not realistic for most SaaS products. Then it became theoretical. Today, with AI, the answer is often yes.

Internal dashboards? Buildable. Workflow tools? Buildable. Automations between systems? Very buildable. Even a useful version of something that looks like a SaaS product is now achievable in a way that would have sounded absurd not long ago.

That is exciting. It is also dangerous.

The danger is not building. Building is good. Building teaches you things procurement never will. The danger is mistaking v1 for ownership.

Because v1 is the seductive part.

You describe the workflow. The tool appears. A form here, a table there, a few automations, maybe a login screen if you are feeling responsible. Everyone gets excited because something that used to require a roadmap, a budget discussion and three prioritisation meetings now exists by Thursday.

But capability is not ownership.

The real question is not "can we build it?"

The real question is: what are we agreeing to own when Murphy shows up?

The checklist before replacing SaaS

This is the mental checklist I now use when evaluating software, both as a builder and as a CRO looking at tools that may affect revenue teams, finance processes, compliance or customer trust.

1. Is the subscription painful enough to matter?

If a tool costs €150 a month, building it yourself to save €1,800 a year is usually not efficient.

If a tool costs €3,000 a month and solves one narrow workflow you understand very well, the conversation changes. The size of the invoice does not automatically mean "build", but it does justify asking better questions.

2. Is the workflow actually simple, or just familiar?

A lot of software looks simple because good products hide complexity. The screen looks obvious. The button is where you expect it. The flow feels boring, which is usually a sign that someone has already absorbed a lot of edge cases for you.

The first version is rarely the problem. The problem is permissions, integrations, audit trails, data quality, error handling, handovers, reporting, onboarding, offboarding and the strange things users do when they believe a tool has become official.

Quick versions are easy. Owned systems are not.

3. Who maintains it after the fun part is over?

This is where many internal builds quietly die. Building v1 can feel magical, especially now. Maintaining it is where reality returns.

APIs change. Users ask for features. The business changes the process. A field that was optional becomes mandatory. A workflow that was local becomes global. Someone leaves the company. Someone else asks why the tool does not support their team's slightly different exception.

Suddenly the internal tool has support, expectations and a roadmap.

When you buy software, maintenance is bundled into the price. You may not like the price. You may complain about the roadmap. But maintenance is part of what you are buying.

When you build it, maintenance is the subscription. You just pay it in time instead of invoices.

4. What happens if it fails?

This is the line between a clever internal build and a major business risk.

If a content tracker breaks, it is annoying. If a parking spot reservation tool fails, people get a little upset, then someone fixes it.

But if a billing, payroll, compliance, expense management, security or customer-facing workflow breaks, the consequences are different. You can lose money. You can create legal exposure. You can damage customer trust. You can make people operate from bad data. You can put the company in a position where the "cheap" internal build suddenly becomes very expensive.

What I still built, and why

After all of that warning, there are still things I would build.

At Rydoo, I built an email signature tool. I built a parking spot reservation tool for the Lisbon office. I built revenue dashboards for myself.

Not because those are heroic feats of engineering. They are not, which is precisely why I did it.

They passed the ownership test.

The problems were bounded. The user need was clear. The blast radius was acceptable. The stakes around sensitive data and broader business impact were relatively low. And I had enough technical understanding to know what I was creating, what could break, and what I would need to maintain.

The revenue dashboards are personal operator dashboards for me, not a replacement for a company-wide finance or BI system. I am both the user and, effectively, the maintainer. If something looked wrong, I had the context to question it. If the logic needed changing, I could change it. If the dashboard broke, the business did not stop.

That is a very different risk profile from replacing a shared reporting layer, a finance process, or a customer-facing system.

The decision rule

Build when the workflow is specific enough that off-the-shelf software is clumsy. Build when the problem is close to the team's expertise. Build when the blast radius is low. Build when the maintenance owner is clear. Build when the learning itself is valuable. Build when ownership is not just acceptable, but actually part of the advantage.

Buy when the workflow is standard and the value is not in customisation. Buy when the system is regulated, cross-functional or high-blast-radius. Buy when the hard part is not the interface but the invisible maturity around it. Buy when outsourced maintenance, auditability, security posture and support are the bargain.

The build-it-ourselves era is real. It is one of the biggest shifts in software buying. It will change SaaS budgets, internal tooling, procurement, product expectations and probably a few vendor pitch decks that needed changing anyway.

But Murphy did not disappear because we got better tools.

Murphy's laws and corollaries

• Nothing is as easy as it looks.
• Everything takes longer than you think.
• Anything that can go wrong will go wrong.
• If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong.
• Corollary: If there is a worse time for something to go wrong, it will happen then.
• If anything simply cannot go wrong, it will anyway.
• If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
• Left to themselves, things tend to go from bad to worse.
• If everything seems to be going well, you have obviously overlooked something.

Keep building!

— Fernando