Spotex Is Over, but Its Liquidation Is Still Blocking My Future

The clients were transferred around two months ago. That was supposed to make an orderly closure possible: no new operations to support, no client portfolio to manage, and no strategic reason to keep a corporate structure open when it no longer had the job of growing a business.

Yet Spotex still exists as a minimal administrative machine that consumes resources:

• an active bank account, with fees and transactions;
• services and invoices that must be checked;
• VAT, tax payments, filings, and official communications to reconcile;
• documents to review, requirements to schedule, and funds to set aside;
• remaining liquidity that is not free capital, but a buffer that must first be used to close everything properly.

This is no longer entrepreneurship. It is no longer product development. It is no longer a growth phase. It is an administrative tail that, if ignored, keeps consuming money and time.

The most visible damage is declining liquidity. Every month can add a bank fee, a forgotten subscription, an invoice, a filing, a professional fee, or a late compliance cost.

But for me, the most serious damage is not even that. It is opportunity cost.

I already have three products that have reached the point where they can be commercialized:

• Linkbay CMS, ready to be set up on AppSumo and launched through Paddle;
• Rstudy, already in a stable first release;
• PivotCut, finished and ready for publication.

These are not folders full of ideas, wireframes, or half-finished prototypes. They are built, refined products ready to be put in front of real users.

The problem is that, as long as the current corporate situation remains unresolved, I cannot safely open the individual tax position needed to start this phase. The paradox is brutal: a company that no longer generates revenue is preventing products that could generate revenue from launching.

I have already written about how a software house can fail even when it knows how to build software. Spotex did not get here because it lacked technical skills, code, or people who could solve problems.

It got here because organizational problems accumulated faster than the company’s ability to manage them:

• weak governance;
• roles and responsibilities that did not match;
• major decisions without a reliable process;
• communication scattered across messages, calls, and silence;
• limited shared visibility into clients, costs, receivables, infrastructure, and priorities;
• an ongoing dependence on the most available person to make things happen.

Liquidation should have been the moment to stop repeating that pattern. Instead, it risks reproducing it perfectly.

Someone says the process can move forward. Someone gives consent to move forward. Then weeks pass. Meanwhile, no one knows exactly which filing has been made, what step is still missing, what funds are actually needed, what has already been done, or who owns the next action.

This is the most sterile form of organizational failure: the company no longer produces, yet it still requires energy to be kept in suspension.

This is not an article written to assign public blame, name people, or turn a corporate closure into a rant. That would be easy. It would also be unhelpful.

Responsibility in a company is rarely comfortable, linear, or perfectly distributed. I made mistakes too. I underestimated warning signs, kept covering operational gaps, and accepted for too long that availability could replace processes, boundaries, and formal responsibility.

But owning my part does not mean accepting paralysis as destiny.

When a business has stopped operating, clients have been transferred, and the partners have expressed the will to close, the process needs a clear path:

1. an updated financial and tax position;
2. a complete list of debts, credits, and obligations;
3. an estimated cost of closure;
4. required documents and signatures;
5. accountable owners;
6. deadlines;
7. an expected date for deregistration.

This is not aggression. It is the minimum required to prevent a dying company from becoming a permanent cost for the people still formally connected to it.

There is also a very concrete fear: that the remaining liquidity will not be enough to cover everything.

When a company stops collecting revenue but continues to incur costs, every month makes closure harder. The money in the bank is not a final prize to distribute: it must first cover taxes, suppliers, bank fees, services, professionals, filings, and every other real outstanding obligation.

The risk should not be dramatized without numbers, but it should not be ignored either. What is needed is a statement. Not reassuring phrases, not "we will see," not "we will speak later." A statement with verifiable amounts and line items:

• available liquidity;
• outstanding receivables;
• certain debts;
• invoices and recurring costs;
• VAT and tax payments;
• professional and registry costs;
• the amount that must be reserved;
• any estimated deficit.

Until these numbers exist in a shared and documented form, no one can honestly say whether the closure will be simple, expensive, or problematic. And the longer it takes, the worse those numbers become.

The most important lesson I am taking from Spotex is not that companies, partners, or clients should be avoided forever. It is simpler and harsher: do not build systems where critical decisions depend on memory, goodwill, or someone’s momentary availability.

Linkbay CMS, Rstudy, and PivotCut are also a response to this experience. I want products built with clear boundaries, understandable costs, documented infrastructure, and technical ownership that is not scattered across chats, emergencies, and silence.

That does not mean doing everything alone out of pride. It means knowing who decides, who owns what, where the data is, how a service is paid for, how a cost is stopped, how a system is handed over, and what happens if someone does not answer for weeks.

Above all, it means not confusing the ability to build software with the ability to sustain a company. Code is only one part of a product. A business also stands on accounting, contracts, communication, processes, access, documentation, and the discipline to make decisions while they are still small.

I am not asking for Spotex to work again. I do not want to reopen discussions about a model that has already proven unsustainable. I do not even want to turn the past into a permanent enemy.

I want to close it properly.

Closing properly means having the numbers, meeting the obligations, paying what is due, preserving the necessary documentation, and reaching a formal ending that allows everyone to stop carrying this structure around.

For me, however, closing is not just about archiving a chapter. It is about freeing the possibility to work on the products I have already built and to start a new activity without living with a constraint created by a model that no longer represents what I want to do.

Spotex taught me a lot. It taught me that technical talent does not compensate for fragile governance. That a client is not always an asset. That revenue does not mean health. That availability is not a role. That documentation is not useless bureaucracy. And that keeping a structure alive when it has no future can cost more than recognizing the end.

Now the lesson needs to end where every serious post-mortem should end: with action. An updated situation. A plan. A date. And a real closure.