Spotex SRL: Four Partners, One Software House, and a Single Bottleneck

For privacy reasons, I will use fictional names. The roles, ownership stakes, and dynamics described here are the ones I experienced directly.

The company had four partners:

• Andrea, CTO, holding 35%: software development, infrastructure, technical support, delivery, and internal products;
• Marco, CFO and chair of the board, holding 35%: finance, the relationship with the accountant, and corporate oversight;
• Luca, COO, holding 15%: operations, coordination, and client relationships;
• Davide, described as CMO and at times as a financial partner, holding 15% through his own company: marketing, sales, and growth support.

At first glance, the structure made sense. The problem was not a lack of titles, but the gap between titles and the work that was actually done every week.

In a small company, a role is not defined by an organization chart. It is defined by what happens when a deadline arrives, a client calls, a payment is late, a server has a problem, or an uncomfortable decision has to be made.

A typical day did not begin with an orderly roadmap, a block of deep work, or the quiet development of a SaaS product.

It began with client messages. Change requests. Tickets. Bugs to reproduce. Websites to update. Quotes to prepare. Services to keep online. A client with an urgent need does not wait for a small software house to sort out its internal responsibilities. They want an answer. And that answer, almost every time, came from the CTO.

At the same time, I was trying to develop the product that was supposed to change the company’s model: a proprietary CMS. The idea was simple: gradually stop living only on custom work and build something repeatable.

But that product had no dedicated team, dedicated budget, protected roadmap, or real division of operational workload. It was built between one ticket and another, one delivery and another, one client problem and another.

After the technical work came the minimum commercial work needed to keep the business alive: looking for potential clients, answering leads, and figuring out whether a project could sustain cash flow and costs. Then I returned to existing clients, because signing a contract does not eliminate maintenance, support, updates, and out-of-scope requests.

And after all that, in the evening, a second shift began: the warehouse shift that was necessary to live. Once the regular shift ended, the computer shift started again.

There were nights when I continued until 3 a.m. Others until 4 a.m. Then I would get up at 7 a.m. and go back to work.

That is not discipline. It is not founder mentality. It is not virtuous sacrifice. It is sleep debt turned into an operating model.

The problem was not working hard. In an early-stage company, working hard can be normal. The problem was the nature of the work: there was no function capable of absorbing chaos without always pushing it onto the same person.

The CTO became, at the same time:

• developer for client projects;
• technical support and ticket management;
• maintainer of hosting, domains, databases, and applications;
• the person who handled emergencies;
• de facto delivery project manager;
• technical contact for clients;
• the person looking for new work;
• developer of the internal product that was supposed to evolve the company.

This structure has a huge flaw: it can appear to work as long as the central person can compensate for everything. Then, suddenly, every delay, error, and new request proves that there never was a system. There was only a person trying to stop it from collapsing.

Telling a difficult situation honestly also means recognizing what others did when they were present and helpful.

During the better periods, Marco sent bank statements from the banking app to the accountant, enabling the preparation of VAT tax payments, and made bank transfers to pay the accountant. This was concrete and necessary work, even if it was not enough on its own to give the company a complete and up-to-date financial picture.

Davide brought in at least one small job worth around 40 euros. The amount was symbolic compared with the company’s needs, but the point is not to mock a single client. The point is to understand the gap between what the structure required and what consistently came in.

At his best, Luca contacted some clients on my behalf and tried to organize the work I had to do. That was real help: having someone absorb part of the communication can reduce the technical burden. But organizing the work of an overloaded person is not the same as creating additional operational capacity.

The problem was not that nobody ever did anything. The problem was that contributions were not consistent, coordinated, or proportionate enough to change the center of gravity of the work. The system remained dependent on one person for most of the activities that kept the company moving or surviving.

One of the most exhausting dynamics was the gap between asking for visibility and helping create the conditions for work to be finished.

The CMS was discussed as a product to commercialize. Tests, updates, demonstrations, and checks were requested. There were discussions about logo, slogan, positioning, and what the company should sell.

These are legitimate discussions. Branding, marketing, and product quality matter. But they become toxic when they are added on top of a system where the person building the product is already overwhelmed by clients, support, delivery, and external work.

A question like “when will it be ready?” is useful only if it comes with a second question: “what do we remove from your workload to make it possible?”

Testing work can improve it. Continuously pressing a person who is already at their limit can only fragment the little time they have left to finish it.

Periodic meetings should have been the moment to look the company in the face: active clients, receivables, recurring costs, planned expenses, revenue, margins, tax deadlines, asset value, and priorities.

Too often, however, the financial picture was reduced to the bank balance and the difficulty of obtaining updates from the accountant.

A bank balance is a data point. It is not a financial strategy.

It does not tell you which invoices still need to be collected. It does not tell you which costs will arrive next month. It does not tell you which services can be cut. It does not tell you which projects are burning hours without margin. It does not tell you what a client who constantly opens tickets really costs. It does not tell you whether an internal product has a budget or is being financed with sleepless nights.

Without a complete view, every decision becomes reactive. You act when a problem arrives, not when the numbers show that the problem is growing.

Having four partners does not mean having four people supporting the company equally. Ownership shares distribute property, rights, and potential economic results. They do not automatically distribute work, operational risk, daily responsibility, or psychological pressure.

This is one of the most dangerous mistakes in small technology companies: confusing the organization chart with the real operating system.

You can have a CTO, CFO, COO, and CMO. But if the CTO remains the only person who closes deliveries, resolves emergencies, speaks with clients, keeps infrastructure alive, and builds the future product, the other roles are not creating a network. They are orbiting the bottleneck.

The question we should have asked earlier was not: “which role do we want to have?” It was: “what result does each role produce every week without one person having to remember it, chase it, or compensate for it?”

In hindsight, I do not think I would have solved everything by working more hours. That was exactly the reflex I needed to stop having.

I would have imposed a few simple rules earlier:

1. One owner for every area, with concrete outputs and a reporting cadence: sales, finance, clients, infrastructure, and product.
2. A monthly operating financial statement, not just the bank balance: revenue, receivables, recurring costs, margins, hours spent, deadlines, and expected cash.
3. A client-support boundary, with timelines, priorities, and billable work, instead of treating every request as urgent.
4. Protected product time, funded and explicitly removed from client delivery work.
5. Documentation for access, infrastructure, contracts, and responsibilities, so the company’s value does not remain locked inside one person’s head.
6. Written decisions, with an owner, date, and consequence if an activity is not completed.
7. A personal sustainability threshold: no project should require someone to work until 4 a.m. and then start another job at 7 a.m. just to remain standing.

These are not big-company rules. They are minimum rules for not building a company on the invisible sacrifice of the person most willing to carry it.

I do not think this experience proves that companies with partners are doomed to fail. It does show that a group of people does not become a company simply because it has ownership shares, job titles, and corporate filings.

A company truly exists when responsibilities are clear, commitments are verifiable, numbers are shared, clients have boundaries, infrastructure is documented, and work does not depend on the heroics of a single person.

The most painful part is that Spotex worked technically for a while. Clients had services. Projects were delivered. Emergencies were resolved. The CMS grew.

But it worked because someone continuously compensated for the system’s flaws with their time, sleep, and availability. No model like that truly lasts.

Today, I do not want to build software that way anymore. I want to build products and systems that can still be maintained tomorrow, with clearer boundaries, more readable costs, more concrete responsibility, and less hidden complexity.