Business Debt: When Teams Shape Systems That Last

Under my beach umbrella, notebook in hand, I listen to the waves and think about what truly makes a project hold up: the people.

This article, part of the "A CTO at the Beach" series, builds on my thinking around Holistic Engineering of development systems. It is a vision where code, hardware, and business teams form a fluid ecosystem, capable of riding the unexpected without sinking into debt -- technical or otherwise.

Why the business must be at the heart

An application project, with or without AI, is like a wave: powerful, but unpredictable. If you do not understand the current -- the real needs of users -- you risk going under.

Too many projects fail because business teams, the people who live in the field every day, are kept on the sidelines. They are given a rigid set of specifications, someone codes in isolation, and a few weeks after go-live, an unforeseen situation brings everything crashing down.

A client who needs two different forms? Not planned for. Another who is both a customer and a supplier? Oops. The result: workarounds in the CRM, duplicates, and "master data" that becomes a nightmare.

This is not just technical debt. It is business debt: shaky processes, poorly covered edge cases, automation that falls apart. Business debt is when the system drifts away from reality, and humans must compensate for design flaws with manual effort.

My solution: involve business teams from the design phase. And that is where the Lean principles inspired by Toyota opened my eyes: start from the field, respect practical knowledge, and design through continuous adaptation.

Listening to the field to surf better

Business teams are the surfers who know the sea. They know what works, what gets stuck, and what can go wrong. But too often, they are left standing on the beach.

Some startups think it is not their role to design applications. And some business teams think they lack the time or skills. Mistake. Their experience is a gold mine.

What do I do? I listen.

I ask simple questions: "What slows you down every day?" and "What unusual cases do you encounter?"

On a recent project, a business team alerted me to clients juggling multiple roles (customer, supplier, partner). Without their input, we would have built a rigid system, incapable of handling these hybrid cases. By involving them, we designed a flexible database, free of duplicates and chaos.

When the business becomes co-builder

Involving business teams is not only useful for avoiding bugs: it is empowering.

At first, there is always a bit of nervousness. Team members do not yet trust the result, sometimes not even their own legitimacy to participate in the design. But very quickly, as soon as they see their ideas translated into a concrete tool -- and especially when we fix issues together -- a sense of pride emerges. It is no longer "the IT tool"; it is their work tool, shaped with them.

And this involvement has a direct managerial impact: users become ambassadors of change, they share feedback with their colleagues, and above all, they take ownership.

Even on the business owner side, you can feel the difference. The tools are better adapted, more robust, and KPIs reflect it.

But often, I have this strange feeling that the real value of the change is hard to capture. Why? Because we quickly forget where we came from: before, it was a pen, a sheet of paper, and a lot of sweat. And especially because the comparison with competitors -- who are still struggling with their old tools -- is rarely measured.

And that is fine: KPIs remain important. But beneath the surface, there is a usage value, a business head start, that you do not always see but that makes all the difference.

Testing with business teams: the key to avoiding surprises

Involving business teams is not just asking for their opinion once. It is having them test from the very first iterations. Why? Because the field reveals truths that no specification document can foresee.

On a sensitive automation project, I had users test from the alpha stage. They spotted a case where a form did not cover a rare but critical situation. We adjusted in a single day, before it became a bug in production.

Testing with the business is like checking your board before surfing. It takes a little time upfront, but it prevents drifting aimlessly later.

Modularity: a system that absorbs shocks

To ride the unexpected, a system must be like a raft: each part can move without sinking the whole. In an SMS project, I designed an architecture where each component -- API, data processing, interface -- was independent.

When the client changed requirements 7 times in a few weeks, we pivoted without rewriting the core. This modularity prevents technical debt, but also business debt, because it allows field feedback to be integrated quickly.

Metrics: seeing the waves before they arrive

A good surfer watches the horizon. In my projects, I integrate metrics from the start: logs, timings, stats on every component. It sometimes annoys IT teams -- too many logs! -- but it is my lookout.

For mAIstrow, my sovereign and frugal AI, these metrics allowed me to optimize inference so it runs fast, even on lightweight hardware. And with business teams, I share this data so they understand what is happening and can suggest adjustments.

Simplicity: the elegance of a solution that lasts

A complicated system is a wave that swallows you whole.

I seek simplicity, like an old 8-bit processor that worked wonders with very little. No need to rewrite everything. Just a light trick, a well-thought-out function, that keeps the solution fluid and lean.

Here too, I learned a great deal from Plan9, the operating system that pushes coherence and simplicity to its absolute limit. A model of functional minimalism.

One last wave before the swim

Building a system is like learning to surf with a team. You need to:

• listen to those who know the sea,
• build a flexible raft,
• and keep your eyes open.

In 30 years of projects, I have learned that the best systems are born when business teams are at the heart of the process.

The Toyota Lean Principles form the backbone of the Toyota Production System and are widely recognized as the cornerstone of lean manufacturing worldwide. The Toyota Way, formalized in 2001, embodies this approach through a set of guiding principles and management practices centered on two pillars: continuous improvement (Kaizen) and respect for people to create solutions that endure.

And on the beach, notebook in hand, I tell myself that this is exactly what we should be doing.

Do you have a tip for involving business teams in your projects? Drop me a line -- I read your feedback between dips in the ocean.