Designing Infrastructure From Almost Nothing
There’s a particular kind of technical challenge that only appears in fast-growing companies.
Not inherited complexity. Not legacy systems. The opposite. Almost nothing exists yet.
No deeply established infrastructure. No sprawling data centre. No decade of undocumented dependencies hiding behind a core switch somewhere. Just people, laptops, cloud services, and a growing awareness that the company is starting to outpace its own operating model.
A cybersecurity company — which I’ll simply call The Company — was preparing to move into a new office. Around sixty employees. A mixture of:
- MacBooks
- Linux laptops
- Windows devices
- engineers
- business development staff
Everything customer-facing already lived in AWS. Internally though, there was almost no centralised IT structure yet. From the challenge brief:
“each employee was relied upon to maintain their own secure environment”
That works for a while in small technical companies. Especially engineering-heavy ones. Trust scales faster than process in the early days.
Until eventually it doesn’t. The challenge wasn’t really:
“design a network”
It was:
“how do you introduce structure without damaging the culture that made the company successful in the first place?”
That is a much harder problem.
The real requirement was controlled flexibility.
The engineering teams needed freedom. The business needed compliance.
The security expectations were high because security was literally the product being sold. At the same time, overly restrictive IT would have been culturally disastrous.
That tension shaped the entire proposal. The starting point I focused on wasn’t firewalls or wireless access points. It was identity.
The first problem was knowing who and what existed.
No matter how modern the infrastructure is, eventually most operational problems reduce to the same questions:
- who has access?
- to what?
- from where?
- using which device?
- and how do you prove it?
The proposal centred around introducing a directory service first. Not because Active Directory solves everything, but because unmanaged growth becomes very difficult to reason about without some kind of authoritative identity layer. At the time, I proposed AWS-hosted Microsoft Active Directory. Not because it was the most elegant solution.
Honestly, part of me preferred the idea of using open systems. I even mentioned 389 Directory as something I would have liked to explore further. But the exercise had a hidden constraint:
limited time and low organisational friction
The fastest stable path mattered more than ideological purity. That’s something experience gradually teaches you.
Good infrastructure is often about reducing organisational resistance.
The proposal then built outward from there.
- site-to-site VPN into AWS
- controlled wireless infrastructure
- separate guest access
- device authentication
- phased onboarding into managed security policies
Nothing particularly exotic. Just layered control introduced carefully enough that the company could continue functioning while becoming more governable underneath. Looking back now, the interesting part is not really the technical proposal itself. Most of the individual technologies have evolved since then. What stayed relevant was the prioritisation.
The first priority was predictability.
Not perfection. There’s a tendency in infrastructure planning to jump immediately toward ideal-state architecture diagrams. But early-stage companies rarely need ideal-state infrastructure. They need:
- repeatable onboarding
- reliable access control
- auditable identity
- sensible separation
- survivable operational processes
The proposal reflected that. A new starter should be predictable.
- account created
- device enrolled
- wireless access controlled
- production access defined
- audit trail established
Not because process is exciting, but because unmanaged growth eventually becomes operational ambiguity. Even the wireless design was intentionally conservative. A small Meraki deployment. Cloud-managed. Simple enough to operate without building a networking team around it.
At larger scale I might have approached parts differently. But for a sixty-person company moving offices while simultaneously trying to achieve ISO 27001 accreditation, operational simplicity mattered more than architectural ambition.
The ISO requirement changed the shape of the whole exercise.
A lot of organisations treat compliance as paperwork layered on top of systems afterwards. In reality, compliance frameworks usually expose organisational ambiguity that already existed.
- Who owns devices?
- How are leavers handled?
- Who can access sensitive data?
- Where is that access audited?
- What happens when someone bypasses process?
The interesting thing about the exercise is that it quietly forced systems thinking. Not:
- “what firewall would you buy?”
But:
- “what behaviour are you trying to create?”
That distinction matters enormously. Because infrastructure decisions become much clearer once you understand the behavioural goal underneath them.
The proposal was less about technology than operational shape.
- Identity before complexity.
- Segmentation before scale.
- Auditability before optimisation.
- Reduce variables.
- Introduce structure gradually.
- Avoid building systems the organisation itself cannot realistically operate.
That last point matters more than people admit. A technically impressive design that exceeds the operational maturity of the company is usually just future instability arriving early.
Looking back, I think the exercise worked because it matched the room.
Not in the sense of “giving them what they wanted to hear”. More that the proposal recognised the actual stage the company was at. A lot of technical people answer infrastructure questions as if they’re designing for a Fortune 500 environment from day one. This wasn’t that. This was a rapidly growing technical company trying to transition from:
“smart people managing themselves”
toward:
“a company capable of governing itself predictably”
without destroying the engineering culture that made it successful.
Looking back, I think they were really trying to work out whether I understood that infrastructure problems are usually people problems wearing technical clothes. And honestly, those are usually the most interesting kinds of infrastructure problems anyway.