Why a Software House Can Fail Even When It Knows How to Build Software

First problem: nobody was actually deciding.

Formal roles existed. On paper. In documents. In minutes. Too bad real authority was something else.

Important decisions didn't follow a process. Weren't documented. Weren't shared. They were made, suffered, or — worse — postponed.

Result: some people worked, others held a title. Governance down the drain.

When partners stop talking, every other problem becomes unsolvable.

Important communications become sporadic. Requests go unanswered. Issues drag on for weeks. Months. Years.

You don't need a hundred employees to have governance problems. Three people who can no longer tell each other things to their face is enough.

Administration became a swamp. Nobody had a clear view of: which clients were active, who owed money, what the recurring costs were, which services were actually profitable, what the assets were worth.

Without those numbers, every decision is a bet. And we kept losing bets.

Classic small-business mistake: confusing revenue with sustainability.

• A client who owes you money isn't cash.
• A contract isn't margin.
• A project that invoices isn't a project that earns.

Three things everyone knows and nobody applies until it's too late.

Clients contributed too. Some paid late. Others demanded support way out of proportion to what they were worth.

The problem wasn't the client who didn't pay. It was the ratio between what came in and what it cost us in work.

For a small software house, a client worth a few hundred euros a year can demand dozens of hours of support, maintenance, emergencies. At that point it's not a client. It's a cost with a friendly face.

Infrastructure was another weak spot. Domains, hosting, VPS, databases, applications, different configs, all piled up over time. No standards.

Non-containerized apps. Systems scattered everywhere. Stuff that needed manual maintenance just to breathe.

Consequences:

• You didn't know where each app lived.
• Backups were an act of faith.
• Moving a service was a nightmare.
• Documenting infrastructure? Never heard of it.
• Cutting costs? Later.
• Emergency response? Panic mode.

At some point rationalization became necessary. Too late. When the situation is already complex, every fix is an emergency response.

The problem wasn't technical skill. That was there.

The problem was the absence of structured management. We worked on emergencies. Not on the processes that prevent them.

Projects, technologies, configs and code written at different times, with no standards for deployment, documentation, backups, monitoring, maintenance.

Result: the technical guy also became sysadmin, DevOps, customer support and — cherry on top — the only one who remembered how each service worked.

A model that holds for two clients. It doesn't scale. Ever.

When you own domains, servers, applications, databases, accounts, contracts and clients, that information has to be written somewhere. Otherwise the company's value lives inside someone's head. And someone's head isn't a company asset.

If that person disappears — or is just on vacation — basic questions become impossible:

• Where does this domain point?
• Which server hosts this client?
• Who has access to this account?
• How are backups done?
• Which application uses this database?
• How much does this client pay?

Documenting isn't bureaucracy. It's what makes your assets sellable, maintainable and assessable. Without it, they're worth zero when someone needs to take the wheel.

Communication degrades invisibly. Unanswered emails. Lost messages. Verbal info. Decisions never written down.

And without a trail, you no longer know:

• Who decided what.
• When.
• Who was responsible.
• Who knew what.
• What tasks were floating around.

Then the unwritten rule of small companies kicks in: "someone has to do it." And that someone is always the most available person. Or the most competent. Or the biggest sucker, depending on how you look at it.

So you end up with operational responsibility and zero decision-making power. Which is the most elegant way to get exploited without noticing.

Over time you make decisions that, in hindsight, don't hold up. It happens.

The real difficulty is telling the difference between an asset and technical work that just keeps the whole thing standing. Domains, clients, contracts, hosting, applications — they have value. But it needs to be analyzed, not taken for granted.

Reducing everything to "how much recurring revenue do we collect" means ignoring custom clients, proprietary software, maintenance, infrastructure, know-how. And it also means not noticing that recurring costs are eating the revenue.

When you notice too late, rationalization is no longer a strategic choice. It's an ambulance.

Putting it all together, this is the heart of the story.

No single problem made the company fail. It was a chain:

weak governance → poor communication → messy admin → low financial visibility → slow decisions → client problems → unmanageable infrastructure → operational overload → destroyed relationships.

Every problem made the next one harder to fix. And eventually the company reached a point where continuing made no sense.

Nobody decided it. It happened. Like almost every bad thing in a company: one small thing at a time.

Liquidation isn't the sudden end. It's the final point of a process that started much earlier.

First collaboration deteriorates. Then governance. Then financial management. Then operations. Finally the moment comes when you have to admit the conditions are gone.

The lesson is simple and it hurts: you can have a technically valid product and still fail.

You can have code, clients, skills, good ideas. But if governance, accounting, communication, processes and financial control are missing, you're building something that works on the desk and collapses in reality.