Before Project Canopy could become a system, we had to answer a simpler question: What kind of device could actually carry personal infrastructure?

That was one of the first practical problems we faced after the idea began moving from concept to infrastructure. At the beginning, it was tempting to think about the project mainly through software: interfaces, access, storage, synchronisation, applications, and communication. Those parts matter, and they would eventually become important areas of work.

But before any of that could become meaningful, we had to solve something more basic. Where would this system actually run?

If personal infrastructure is meant to give people more control over their data, then it cannot only exist as an idea. It cannot only live in policy language, diagrams, or a user interface. It needs a physical layer. It needs something the user can own, power, connect, and control.

That became the first challenge.

An App Was Not Enough

One of the earliest lessons was that an app or a conventional SaaS alone could not solve the problem.

An app can help someone access a system. It can make something easier to understand. It can provide an interface, simplify actions, and make complex infrastructure feel more approachable.

But an app is not infrastructure by itself.

If the data still lives somewhere else, on someone else’s servers, inside someone else’s platform, or behind someone else’s terms, then the app is still only a window into another system. It may improve the experience, but it does not fully answer the ownership question.

Project Canopy needed more than a window. It needed a place where the user’s data and control could actually reside. It needed a foundation that was closer to the user than a cloud account, more direct than a hosted service, and more personal than infrastructure owned by a third party.

That was when the project became physical. The question was no longer only, “What software should we build?” It became, “What should this software live on?”

Looking at What Already Exists at Home

The first place we looked was the home.

Most people already have a device that stays powered, stays connected, and quietly keeps their digital life online: the modem or router. It is not something people think about every day, but it already plays an important role. It sits between the home and the internet. It is familiar. It is always there. It already represents a kind of personal gateway.

That made it an obvious place to explore. Could the system use what already exists in the home? Could a modem or router become the starting point for personal infrastructure? Could a USB storage device connected to a router act as a simple private cloud?

At first, some of these ideas looked promising. A modem already has power and connectivity. Some routers already support USB storage. A USB drive is inexpensive and easy to understand. The concept sounded simple: place storage closer to the user, use the home network, and avoid relying on centralised cloud storage.

But once we looked closer, the limits became clear.

A USB drive can store files, but it is not a computing platform. It does not have the processing capability, security model, application layer, or communication logic needed to act as personal infrastructure. It can hold data, but it cannot meaningfully manage the system around that data.

A modem or router may already connect the home to the internet, but most consumer networking devices are not designed to be open, flexible, user-controlled application platforms. Many are closed, limited, difficult to modify, or risky to depend on beyond their intended purpose.

More advanced routers and network-attached storage devices offered more capability, but they introduced a different problem. They could become too expensive, too complex, or too far away from what we wanted as a practical starting point for everyday users.

Each path taught us something. The simplest-looking solution was not always the most suitable one.

The Problem Was Control

The hardware question was not only about performance. It was about control.

That mattered because the purpose of Project Canopy is not simply to create another place to store files. It is about exploring what personal infrastructure could look like when the user has more direct ownership and authority over their digital environment.

If the foundation depends on hardware that cannot be properly configured, secured, maintained, or extended, then the system becomes limited from the beginning.

That was one of the reasons we had to move beyond “what is available?” and ask a harder question:

What kind of hardware gives us enough control to build the system properly?

The device had to be affordable enough to make sense. It had to be small enough to live in a normal home. It had to be efficient enough to remain powered without becoming a burden. It had to support storage, networking, software updates, secure communication, and future expansion.

It also had to be something we could build on with intention. This is where the hardware decision became more than a hardware decision. It became part of the product philosophy.

A personal infrastructure device cannot only be powerful. It has to be practical. It has to be understandable. It has to be maintainable. It has to be able to sit quietly in someone’s environment without asking them to become a systems administrator.

That balance was not obvious at the beginning.

Storage Was Only Part of the Problem

At first, it is easy to describe the challenge as storage. Where do the files live? Where is the data kept? What device holds it? But over time, we realised the deeper problem was not only storage. It was presence.

Personal infrastructure needs to be available. It cannot behave like an external drive that only matters when someone plugs it in. It needs to sit inside the user’s environment and remain ready. It needs to support communication between the user’s own devices and their data. It needs to become part of the everyday digital environment, not an occasional accessory.

That changed how we thought about the device. It was not just a storage box. It was a node.

A storage device holds data. A node participates in a system. It can run services, respond to requests, manage communication, enforce rules, and become part of a broader architecture. That shift was important.

Once we understood that Project Canopy needed a node, the first challenge became clearer. We were not simply choosing where files should sit. We were choosing the first physical layer of a personal infrastructure system.

Why Dedicated Hardware Became Necessary

Dedicated hardware became necessary because the system needed a foundation that could grow with the idea.

That does not mean every other option was useless. In fact, exploring those options helped shape the project. Looking at modems, routers, USB storage, travel routers, and more advanced storage devices helped us understand what the system should avoid depending on.

It should not require users to modify their modem. It should not depend on fragile router settings. It should not assume every home has advanced network equipment. It should not begin with a solution that is too closed, too limited, too expensive, or too difficult to explain.

The system needed a device that could be owned by the user, shaped by the project, and improved over time. That is why the idea of a dedicated home node became important.

A dedicated node gave us a cleaner foundation. It allowed the system to have its own software layer, its own security assumptions, its own update path, and its own role inside the broader architecture. It made it possible to think beyond storage and toward communication, access, applications, and eventually a wider personal infrastructure model.

The first answer was not final. But the direction became clear. Project Canopy needed a physical base that users could actually own and that we could actually build around.

From Device to System

Once the hardware direction became clearer, the project itself started to change shape. The question was no longer only: What device should hold the data? It became: What responsibilities should live on the device, and what responsibilities should live elsewhere?

That question opened the path toward the broader system.

The physical node would need a core software layer. Users would need an interface to interact with it. The system would need ways to communicate securely. It would need to work locally first. It would eventually need a way to connect beyond the home without asking people to expose their home network directly.

Those became later problems. The first problem was more basic. Before Project Canopy could communicate, synchronise, route, or scale, it needed somewhere to exist.

It needed a home.

The First Layer

Looking back, this was one of the earliest and most important lessons in the project.

Personal infrastructure cannot stay abstract forever. At some point, it has to meet the real world: power cables, storage limits, network ports, cost, heat, reliability, and the ordinary conditions of everyday homes.

That is where the concept starts becoming real. For us, the first challenge was not software. It was deciding what kind of physical layer could make the idea practical. That answer shaped everything that followed.

Project Canopy began to take form when we stopped treating data ownership as only a principle and started treating it as something that needed a foundation. A user-owned system needs a user-owned place to run. A personal internet needs a personal layer. A new model of data ownership needs more than a promise.

It needs infrastructure. And before infrastructure can do anything else, it needs somewhere to live.