We did not build manual scaling dials into Symbiosis because we do not want our product, or our team, to depend on someone being awake at the right moment. That decision is a direct consequence of our engineering culture: ship, not fixes.
This is not a slogan we added after building the platform. It is one of the constraints we used while making architectural decisions. Symbiosis is an AI-optimized managed cloud hosting and edge deployment platform, and its product promise is simple: no SRE needed. For that promise to mean anything, the system has to do more than give people a better dashboard for reacting to incidents.
The terminal should not be the control plane
There is a familiar pattern in infrastructure. A service receives a sudden increase in traffic. Capacity runs short. Someone gets paged. They inspect metrics, decide which setting to change, adjust a scaling dial, and wait to see whether the change helped. If it did not, they repeat the process.
That pattern can be made more disciplined. It can have better alerts, clearer runbooks, and more carefully defined escalation policies. But the core relationship remains the same: the system waits for a problem, then asks a person to intervene.
We made a different choice. Symbiosis uses AI prediction to shift capacity before spikes arrive. The goal is not to make a 3am response more efficient. The goal is to make the 3am response unnecessary.
That is also why we do not expose manual scaling dials as the centre of the product experience. A dial can be useful when a person already understands the situation and has time to respond. It is a poor substitute for infrastructure that anticipates demand and acts before capacity becomes the problem.
What happens at 2am
Imagine a traffic spike beginning at 2am. In an incident-first system, the first meaningful signal may be an alert: latency is climbing, error rates are increasing, or instances are running out of room. The on-call person opens a terminal, checks the state of the service, and starts making changes under pressure.
At Symbiosis, the intended sequence is different. The platform predicts the increase, shifts capacity ahead of it, and keeps the deployment moving without asking a person to adjust infrastructure manually. The team wakes up to a system that handled the event, not a queue of urgent decisions.
The point is not that nothing can ever go wrong. Systems fail. Predictions can be wrong. Deployments can introduce problems. We are not saying you should never respond to incidents; we are saying incidents should be rare enough that they do not define the culture.
For us, the difference matters because Symbiosis is a three-person team: Marcus Lindqvist, our CTO; Elias Makinen, our Head of Infrastructure; and me. We cannot afford a 3am operations culture. More importantly, we do not think the size of our team should be the only reason to reject one. People should not have to build their lives around the possibility that a machine will need a human to turn a knob in the middle of the night.
“Ship, not fixes” is a design constraint
When we say ship, not fixes, we are not arguing for careless releases or pretending that operations do not matter. We are saying that engineering work should reduce the number of recurring problems rather than normalise their manual treatment.
A fix closes the immediate gap. A product decision can remove the gap from the operating model altogether. Predictive capacity is that kind of decision. So is the 14ms cold-start average. Both are part of a broader expectation that deployment and runtime behaviour should be fast enough, predictable enough, and managed enough that customers do not need a specialist team standing between their application and its infrastructure.
This culture changes the questions we ask. Instead of asking, “How do we make this alert easier to handle?” we ask, “Why does this require an alert at all?” Instead of asking, “Where should we put the scaling control?” we ask, “Can the platform make this decision automatically and earlier?”
The cost of avoiding fires
This approach is not free. It requires more work in the infrastructure and in the product. Prediction has to be useful before a spike, not merely accurate after one. Capacity has to be available where it is needed. Deployments need to remain simple enough that automation does not create a new category of operational confusion.
It also requires restraint. We cannot solve every edge case by adding another control, another override, or another page. Every manual escape hatch creates a responsibility for someone to understand, maintain, and eventually use it under stress. Some controls are necessary. But adding controls is not the same as removing operational burden.
Our standard is therefore demanding: the platform should carry as much of the routine operational work as possible, while keeping the remaining behaviour understandable. “No SRE needed” is not a claim that infrastructure is trivial. It is a commitment to put the complexity in the platform instead of asking every customer to assemble an operations function around it.
Culture is visible in the architecture
Symbiosis was founded in Stockholm in 2024, and we are building it as a bootstrapped company. Those facts make focus important, but the underlying principle would remain even if the team were larger. An engineering culture is not the set of values written on a wall. It is the set of tradeoffs that survive contact with the product.
We chose predictive capacity because we do not want to ship a platform that waits for customers to experience a fire before helping them manage it. We chose not to make manual scaling dials central because we want the system to act before a person has to. We measure the quality of the result not only by whether a service recovers, but by whether recovery had to become someone’s night.
The strongest cultures are encoded in systems. If the architecture assumes constant intervention, the team will eventually become an intervention team. If the architecture is built to prevent predictable fires, the team has room to ship. At Symbiosis, culture and architecture are coupled by design: what we believe about engineering determines what the platform is allowed to ask of people.