- Zen IT Technologies
- Network & Infrastructure
Nobody notices a network that works.
Wi-Fi that drops in the same corner of the office. A firewall carrying rules added at 2 a.m. four years ago. A server room that grew over the years without a plan. Network problems get tolerated for years because each one on its own is survivable. Together, they make an office feel like it is fighting the people in it.
We design networks deliberately: understand the environment, map the paths, then decide how traffic should move and where it should stop. Then we build them and run them. From copper to cloud.
The problem
Most networks were not designed. They were extended.
There was a plan once, for a smaller company in a different office. Everything since has been an addition: an access point where the complaints were loudest, a firewall rule to unblock somebody on a deadline, a switch bought when the ports ran out. Every individual change was reasonable. The result is not.
These are the failures we get called for, and they repeat:
-
Wi-Fi that fails in the same places.
Access points positioned for cabling convenience rather than coverage, channels overlapping each other and the neighboring tenants, and transmit power turned up until the cells collide with themselves.
-
A firewall nobody will touch.
Rules accumulated over years, each added for a reason that was never written down, and now nobody will remove one in case something stops working.
-
Core services pointing at themselves.
Time and name resolution configured in a hurry, then quietly responsible for years of certificate and authentication failures that appeared to have nothing to do with either.
-
One flat network.
Guests, staff, printers, cameras and IoT sharing a single segment, because separating them was always going to be a project for next quarter.
-
A server room that grew without a plan.
Unlabeled cabling, no patching record, and a rack only one person knows well enough to work in safely.
-
Nobody knows what changed.
No topology, no VLAN plan, no channel plan, and equipment still running the firmware it arrived with because nobody is sure what depends on it. The next change is guesswork and the last one is hard to reverse safely.
What network infrastructure covers
- Internet / WAN
- Remote users
- Other sites
- Cloud networks
Identity and device context informs access decisions where supported
- Corporate wired
- Corporate Wi-Fi
- Guest and IoT
- Private / cloud resources
Network operations and lifecycle
-
Wireless design and RF survey
Predictive survey before any hardware is bought, based on floor plans and construction materials rather than on where the sockets are. Access point placement, channel plan and transmit-power plan designed together, because raising power without planning channels is what causes most of the problems it is meant to solve. Controller configuration, followed by a validation survey to confirm the design survived contact with the building. High-density and multi-floor environments included, where the interference that matters is usually coming from your own floors.
-
Internet edge and firewall policy
Policy review and rule consolidation, with each surviving rule attributable to a reason. Review of what is reachable from outside, with management interfaces limited to the networks and locations they should be reachable from. Where a rule set has grown for years, the useful work is establishing what it currently permits before deciding what to remove from it.
-
WAN, remote access and cloud connectivity
Users, sites and cloud resources rarely sit behind one firewall. Remote access may terminate on a firewall, in the cloud, or through a dedicated access service. We design and troubleshoot site-to-site and hybrid connectivity across office networks, AWS and GCP, with failover where justified. Bringing up the tunnel is rarely the difficult part; routes, address space and filtering usually are. Where the standard path does not fit, we build one: a jump host into a private environment.
-
Wired LAN, switching and segmentation
VLAN design that separates guests, corporate devices, printers, cameras and IoT, with inter-VLAN policy written deliberately rather than left open. A VLAN only becomes a boundary where traffic between segments passes through something that can enforce policy, and that is decided by where the gateway sits. Uplink and trunk design, PoE budgeting that accounts for what the access points actually draw, and a documented port map so the next person can find things.
-
Routing, addressing and network services
Internal routing and an address plan with room for the site after this one, so two environments that later need to reach each other are not already using the same private ranges. Then DHCP, DNS and NTP designed deliberately rather than inherited from whatever the router happened to provide: consistent DHCP options across sites, appropriate internal or managed resolvers, reliable time sources, and upstream services configured without circular dependencies. Unglamorous, and the cause of a surprising share of certificate and authentication failures.
-
Office and site buildout
New offices, relocations and floor expansions, from server room to desk. Structured cabling and rack design, meeting-room and AV technology, physical security and IoT equipment, and the coordination with contractors and landlords that decides whether the network is ready on the day people arrive.
-
Network operations and lifecycle
Uptime and reachability monitoring with alert routing that goes to a person rather than an inbox, plus what only shows up over months: circuit health, capacity and configuration drift. Firmware and support status tracked across firewalls, switches, access points and controllers rather than only at the edge, with configuration state kept so there is a known recovery path where one is practical. Topology, VLAN map, channel plan and runbooks maintained as part of running the environment, so somebody other than us can understand how the network is built.
Network access, identity and device context
Network access does not have to mean that anything plugged into a socket, or anyone holding the wireless password, is on the corporate network. Where the equipment and the client devices support it, a port, a wireless network or a remote-access service can check with the identity provider, through RADIUS, 802.1X or a ZTNA service.
The ownership matters more than the mechanism. Identity is where the user and their groups come from. Endpoint management is what can say something about the device. The network, or the access platform in front of it, enforces the decision on a connection. We build the integration between them; none of the three owns the whole control.
Technical notes
Why office Wi-Fi fails at capacity, not coverage
Adding access points to a congested floor usually makes it slower.
How it runs
-
Discovery.
What is actually deployed, how it is configured, and where the traffic really goes: topology, circuits, routes, versions and the RF environment where wireless matters. Symptoms first, not the cause somebody assumed.
-
Design.
Topology, addressing and routing, the segments and the policy between them, how sites and cloud environments connect, resilience where justified, and the wireless plan. Written and agreed before hardware is ordered.
-
Deployment.
Staged and preconfigured, with an agreed cutover, validation and a rollback path. Where interruption is unavoidable, it is planned and communicated rather than discovered during the change.
-
Managed.
Monitored and adjusted as the sites and the headcount change, with firmware, configuration state and capacity tracked rather than rediscovered. The channel plan survives someone else touching it because it is documented.
Proof
-
An office Wi-Fi deployment that stopped generating tickets.
AI infrastructure company
Predictive RF survey, channel and transmit-power planning, followed by a controller rebuild. The Wi-Fi support queue emptied and stayed empty.
-
A multi-floor office network designed before the fit-out.
Technology company
Access point placement, channel plan and switching designed from floor plans ahead of construction, so the network was commissioned alongside the office rather than remediated after everyone had moved in.
-
Core network services rebuilt across sites.
Financial services company
Internal time and name resolution moved off self-referential upstream configuration onto dedicated internal services, rolled out across sites by DHCP option, with the design and a runbook handed to the internal team.
Client examples are anonymized by design. References are provided privately, on request, and with the client's consent.
Who this is for
Companies with a physical office where the network has become a recurring subject in conversations it should never appear in: a standup, a board meeting, an all-hands. Teams fitting out a new space, expanding onto another floor, or arriving at a building where the previous tenant's cabling is now their problem.
Also companies who suspect the answer to a chronic complaint is not more hardware. It frequently is not. Adding access points to a badly planned deployment usually makes it worse, and we would rather survey first and tell you that.
You do not need an office to need this. VPN, routing, cloud connectivity and remote access still need someone to design and troubleshoot the path. We own the network side of that problem; application and platform engineering remain outside this service.
Frequently asked questions
-
Do we need a survey, or can you just add more access points?
Usually, yes. “The Wi-Fi is bad” can describe several different problems, and coverage is only one of them. Access points on the same channel can end up sharing the same airtime, so adding more hardware to an unplanned deployment can make the symptom worse rather than better. A survey shows what is actually happening and often reduces the amount of hardware you need.
-
Our Wi-Fi is slow. Is that the internet or the network?
Those are different problems with different fixes, and the answer is usually visible quickly. Circuit saturation, misconfigured QoS, an RF environment where clients are retransmitting, and a DNS resolver adding latency to every lookup all present as “the Wi-Fi is slow” to the person experiencing it. Establishing which one it is takes a lot less time than most people expect.
-
Can you connect our office to AWS or GCP, or is that a different kind of consultant?
That is this service. We handle site-to-site connectivity, routing, address planning and the network policy that determines whether the environments can actually reach each other. The tunnel itself is often the easy part. Application architecture and deployment are separate; if the problem sits there, we will say so.
-
Can you work with our existing hardware, or does this mean replacing everything?
Most engagements start by configuring what you already own properly, and a meaningful share of them end there. Where we recommend replacement, it is because the platform cannot meet a specific requirement such as capacity, standards support or supported firmware. We explain the reason before anything is ordered.
-
Do you do the physical work, or only the design?
Both, in Israel: server rooms, racks, cabling, access points, switching, and the IT, IoT, security, and AV equipment that goes with them, including meeting-room technology. Internationally, the design, configuration and validation are remote, and we coordinate the physical installation with local technicians. Configuration and management are identical either way.
-
What happens to the network after you build it?
You get the topology, the VLAN map, the channel plan, the configuration state and the runbooks, and they are yours whether or not the relationship continues. From there it is either handover to your team or ongoing management as part of a wider engagement.
Find out what your network is actually doing.
A 30-minute call with Jonny. We reply within one business day.