The assumption we rejected is that an infrastructure company must raise venture capital early to build enough hardware, locations, and capacity to matter.
It is an understandable assumption. Infrastructure costs money before the product is fully visible. Hardware has to be selected and installed. Points of presence have to be commissioned. Systems need to be operated long enough for their weak spots to appear. Compared with a software application that can ship a new feature in a short cycle, infrastructure often takes longer to build, test, and improve.
That difference creates pressure. If outside funding arrives, the company may be expected to grow quickly, expand its scope, and demonstrate that it can support a much larger business than the one it has actually built. We decided that pressure was not the right starting point for Symbiosis.
Bootstrapping was a deliberate choice
Symbiosis is an AI-optimized managed cloud hosting and edge deployment platform. Marcus Lindqvist, our CTO, Elias Makinen, our Head of Infrastructure, and I started the company in Stockholm with a clear view of what we wanted to learn first.
We wanted to build the infrastructure, operate it, and pay close attention to the feedback it produced. That feedback does not arrive all at once. A hardware decision may only reveal its full consequences after systems have been deployed and used. A new PoP can create useful capacity, but it also creates operating responsibilities and a direct cost.
Bootstrapping gave us permission to let those learning cycles set the pace. The choice was not a statement that outside capital is always harmful. It was a decision about which constraints would help us make better decisions during the early build.
What the choice changed
Today, Symbiosis has 12 PoPs, and they have been built while bootstrapping. That number is not a target we chose to inflate for a presentation. Each location represents a hardware decision with a direct cost consequence. We have to ask whether a proposed expansion helps us serve the product we are building, whether we can operate it properly, and whether the timing makes sense.
That makes some decisions easier. We do not need to add a feature or commission another location simply to support a growth narrative. If a capability does not improve the product or help us learn something important, we can leave it out. Revenue and useful product progress matter more than growth for its own sake.
Other decisions are harder. We cannot treat every worthwhile investment as immediately affordable. A venture-backed infrastructure company may have more room to make a large hardware commitment before revenue catches up. We have to be more patient and more exacting. We may delay an investment, narrow its scope, or sequence it behind a decision that has a clearer relationship to customer value.
That tradeoff is visible in product scope. We are building toward the product launch in August 2025, but we are not trying to arrive with every possible feature or deployment pattern. A smaller scope gives us fewer variables to manage and makes the feedback more useful. It also keeps the team focused on the parts of managed cloud hosting and edge deployment that need to work first.
The incentive we wanted
Infrastructure companies often have a longer time-to-revenue than SaaS applications. The costs begin early, while the evidence that the system is working accumulates over time. That can make growth metrics especially tempting. They are easier to point to than a careful operating decision or a product boundary that prevents future complexity.
We wanted our incentives to remain close to customers. If a customer pays for the product, that revenue is useful evidence. It tells us that what we built has value and gives us a practical basis for deciding what to improve next. It does not answer every question, but it is more grounded than expanding because the company needs to appear larger.
Venture capital can push infrastructure companies toward premature feature expansion. The funding itself is not the problem. The challenge is that capital often comes with expectations about the pace and size of the opportunity. Those expectations can lead a team to add products, locations, or capacity before the core system has produced enough feedback.
We are not saying VC-funded infrastructure companies are wrong; we are saying the incentives pull in a direction that did not fit what we wanted to build.
What bootstrapping costs
Bootstrapping is not a free pass to build slowly. It removes a cushion. There is no large reserve that allows us to make every hardware investment at once, and no outside capital to absorb a long period between spending and revenue. The team has to be careful about cash, scope, and sequencing.
It can also mean slower hardware investment. If a larger deployment would improve the product but does not yet have a responsible financial case, we may need to wait. That can be frustrating. Infrastructure benefits from scale, and waiting can mean that some opportunities take longer to pursue.
There is a personal cost as well. Bootstrapping asks the founders and team to remain close to the details for longer. We cannot separate product decisions from infrastructure operations or financial consequences. That is demanding, but it is also useful. The constraints are visible, and the connection between a decision and its result is difficult to ignore.
Building at the pace of understanding
Our goal is not to make bootstrapping part of Symbiosis's identity for its own sake. The goal is to build an infrastructure company whose pace matches what we actually know. With hardware and PoPs, confidence should come from operating the system, learning from it, and earning the ability to expand.
That approach has shaped Symbiosis from the beginning. It has influenced our product scope, our iteration pace, and the way we think about every new commitment. As we move toward the August launch, we would rather have a system we understand and can improve than a larger promise built ahead of the evidence.