Before we had customers, we were deciding how much power to reserve in a Stockholm colocation facility for a product that did not exist yet.
That was the uncomfortable reality of commissioning Symbiosis's first PoP nodes. We were a small, bootstrapped team, and every hardware and colocation decision had a direct cost. We could not wait for traffic data to tell us what to buy. There was no traffic data. There was no product in production. There was only a technical direction, a list of assumptions, and a growing set of invoices.
Our first batch was commissioned before the product launched in August 2025. Since then, the architecture has grown to 12 PoPs across five continents: Stockholm, London, Amsterdam, Frankfurt, Paris, New York, Chicago, Los Angeles, Sao Paulo, Singapore, Tokyo, and Sydney. The geography is easy to list. The harder part was learning what a PoP actually requires when you are building one before the market has told you what it needs.
The first decision was not about servers
Our first Stockholm setup was deliberately modest. We chose a single rack in a colocation facility, with reserved power, redundant network paths where available, and remote-hands support for the work we could not perform ourselves. The choice was less about maximum capacity than about limiting the number of irreversible decisions.
We had several competing risks. A larger deployment would give us more room to grow, but would tie up more capital before launch. A smaller deployment could constrain us if demand arrived quickly. A facility with excellent connectivity might still be a poor operational choice if access procedures, replacement parts, or remote support made ordinary maintenance slow.
In the end, the question was not “What is the ideal data center?” It was “What is the smallest operating environment that lets us learn safely?” That framing helped. We looked for predictable power and connectivity, practical access, clear escalation paths, and enough room to add capacity without rebuilding the whole site.
The server decision followed the same logic. We wanted hardware that could run the workloads we expected, but we did not want a design so specialized that a failed component became a long outage or an expensive one-off purchase. Standardization mattered more than chasing every possible performance improvement. A repeated configuration is easier to provision, document, monitor, and replace.
A PoP is a physical system
Cloud-native engineering can encourage a useful but incomplete mental model. We are used to treating infrastructure as code, replacing instances through automation, and assuming that capacity can be requested when needed. Those assumptions are valuable inside a cloud environment. They are not a substitute for a physical PoP.
A PoP requires decisions about power draw, rack space, upstream connectivity, cabling, hardware failure, spare parts, shipping, access windows, and who can touch the equipment when the team is in another time zone. It also requires a plan for the boring failures: a dead drive, a faulty power supply, a mispatched cable, a router that needs a physical reset, or a delivery that arrives later than expected.
This is the boundary we had to make explicit: cloud-native patterns can describe how software should be deployed, but they do not remove the physical responsibilities of edge infrastructure. A deployment manifest cannot replace a power budget. Automated provisioning cannot replace a remote-hands procedure. A health check cannot repair a disconnected cable.
We began documenting each PoP as both a software environment and a physical site. The documentation covered the intended topology, addressing, port assignments, hardware inventory, replacement process, and escalation contacts. It also recorded the assumptions behind the design. Assumptions are easier to revisit when they are written down than when they are hidden in a purchase order.
Designing without traffic
The hardest technical problem was capacity planning with no meaningful workload history. We had to estimate the shape of demand before we knew the product's usage patterns, regional distribution, or the balance between compute, storage, and network traffic.
That made peak capacity a poor sole target. We focused instead on operational flexibility. Could a node be brought into service without a custom process? Could we add capacity in stages? Could a failed machine be replaced with a known configuration? Could we identify a site problem without confusing it with an application problem?
We separated what had to be consistent globally from what could vary by location. The baseline software and provisioning process needed to be repeatable across Stockholm, London, Tokyo, and the other PoPs. Local connectivity and physical arrangements could differ because each colocation environment has its own constraints.
That separation reduced the risk of treating every site as a bespoke project. It also exposed where our early plans were too optimistic. A topology that looked clean on a diagram could become awkward once it met a facility's available ports, rack layout, or installation rules.
What we got wrong
We initially underestimated the operational cost of small differences between sites. A variation in cabling, labeling, or access procedure may look harmless when commissioning one location. Across a growing fleet, it creates additional instructions, additional opportunities for mistakes, and additional time spent diagnosing whether a problem is local or systemic.
We would standardize the physical runbook earlier. Not just the server image and configuration, but the rack diagram, labels, cable lengths, spare inventory, acceptance checks, and handoff between our team and the colocation provider. We also would have made the first validation process more deliberately repetitive. Doing the same checks at every site is less interesting than improvising, but it produces better information.
We also learned that “available” is not the same as “operationally useful.” A node can be powered on and reachable while still lacking the monitoring, replacement path, or documented access needed to trust it. Commissioning ends when the site can be operated predictably, not when the lights turn on.
Building for the next decision
Because we were bootstrapped, we could not build every possible capability in advance. We had to choose which uncertainties were worth paying to remove. The answer was usually not more equipment. It was better visibility, clearer failure handling, and a deployment process that let us compare sites and identify differences quickly.
Each new PoP became both an expansion and a test of the earlier design. Stockholm gave us a starting point. London, Amsterdam, Frankfurt, and Paris challenged our assumptions about regional operations. The North American, South American, Asian, and Australian locations added more variation in distance, logistics, and support. The architecture had to become more repeatable without pretending that every physical site was identical.
That is the central lesson from building PoP infrastructure from scratch: the first job is not to predict the future perfectly. It is to make uncertain decisions reversible where possible, visible where they are not, and repeatable enough that the next decision is informed by the last one.
We started commissioning nodes before we had a product, customers, or certainty. That did not make the uncertainty disappear. It gave us a physical system in which to learn, and an operating foundation for the product we were still building.