Why I Chose UniFi

I wanted a network I could learn from without making reliable household Wi-Fi depend on a collection of equipment I was still reverse-engineering.

When I redesigned my home network, I wanted something between basic consumer gear and a collection of enterprise equipment that would become its own maintenance project.

UniFi fit that space for me.

It gave me one operating model for the gateway, networks, VLAN-aware Wi-Fi, access points, client visibility, and policy. It also let me practice concepts that transfer to larger environments without pretending the platform is identical to every enterprise network.

The decision was not about finding the most powerful networking platform.

It was about finding the balance I was willing to operate every day.

The decision contract came before the brand

The original version of this article described why I liked the result, but it did not make the selection criteria explicit enough.

If I were recording the decision now, I would start with the requirements rather than the vendor name.

Requirement	Why it mattered	What counted as enough
Multiple trust zones	Personal, guest, IoT, homelab, and work devices should not all share one policy boundary	VLAN-backed networks with controllable inter-network policy
Multiple access points	One radio was not the coverage design I wanted	Centrally managed APs with wired uplinks where practical
Central visibility	Troubleshooting should not require checking unrelated device interfaces one by one	Client, AP, network, and policy state visible in one management application
Deliberate discovery	Some casting and service discovery must cross selected network boundaries	Controlled mDNS/discovery behavior rather than flattening the network
Manageable operations	Household connectivity still needs to work when I am not interested in doing lab work	A platform I can update, troubleshoot, and document without making every change a custom project
Room to learn	I wanted real VLAN, routing, firewall, wireless, and segmentation work	Enough control to expose the networking concepts instead of hiding all of them
Sensible replacement path	A failed AP or gateway should not force a complete redesign	A product family and configuration model I can replace incrementally

There were also things I did not require.

I did not need the deepest possible routing feature set, carrier-scale wireless management, a pile of vendor certifications, or a design that maximized CLI exposure simply because those capabilities exist.

Those could be valid requirements in another environment.

They were not my requirements here.

That distinction matters because a networking platform can be objectively more capable and still be the wrong fit for the job.

The alternatives were not wrong; they optimized for different things

I find the decision easier to explain when I compare categories rather than pretend UniFi had no competition.

This is a decision record, not a claim that every product in each category behaves identically.

Approach	What attracted me	What made it less attractive for this deployment
Consumer all-in-one / mesh	Low setup burden, simple household operation	Segmentation, policy visibility, and lab experimentation can be limited or highly product-dependent
DIY/open networking stack	Maximum control, strong learning value, replaceable components	More integration and maintenance responsibility than I wanted attached to household connectivity
Used enterprise gear	Deep feature sets, excellent learning potential, strong hardware value in the right market	Licensing, controller, noise, power, support, and lifecycle questions vary widely and could become a project of their own
UniFi	Integrated management, VLAN-aware wired/wireless design, useful visibility, approachable operations	Ecosystem dependence, abstraction, and less low-level control than some alternatives

The important result is not that UniFi “won” every column.

It did not.

It won the combination I cared about: enough network control to learn and segment the environment without making routine household networking an infrastructure hobby every night.

If my goal had been primarily learning routing protocols or building the most vendor-neutral stack possible, I could have made a different choice.

The network needed more than one trust level

A flat home network is convenient until it contains work systems, servers, cameras, televisions, assistants, game consoles, personal devices, and guests.

Those devices do not all need the same access.

My design separates the environment into broad roles:

primary personal devices;
guests;
IoT equipment;
homelab services;
work systems.

The names are less important than the boundaries.

A guest device should not need access to the homelab. An IoT device should not automatically share a trust level with a work computer. A server may need to answer selected requests without being reachable from every device in the house.

Current UniFi Network supports VLAN-backed virtual networks, network isolation, firewall policy between routed zones, SSID-to-network assignment, and additional device-isolation controls depending on where the policy needs to be enforced.

Those features made the trust model easier to express from one system.

They did not design the trust model for me.

The gateway became a policy boundary, not “the whole network”

In my deployment, the gateway is an important routing and policy boundary, while UniFi Network provides the management view used to define and inspect the environment.

I am more careful with that wording now because a UniFi deployment does not have to use one universal topology. UniFi Network can manage networks and devices in different supported designs, and some functions depend on whether a UniFi gateway or Layer 3 switch is present.

The useful lesson is architectural rather than product-specific:

A VLAN does not exist only as a colored box in a controller.

The network definition, routing boundary, switch path, AP uplink, SSID mapping, and policy all have to agree about where the traffic belongs and whether it is allowed to cross into another zone.

The interface lowers the barrier to making those changes.

It does not remove the consequences.

A rule can still block the wrong traffic. An allow rule can still be too broad. A network can be isolated enough to break a feature that quietly depended on local discovery.

The application shows configured intent and useful observed state.

I still need to understand the path.

Multiple wired access points solved a coverage problem

I use multiple wired access points rather than asking one radio to cover the entire building.

The goal was not simply maximum signal strength.

It was consistent coverage across the space without expecting one device to punch through every obstruction.

Wired uplinks keep the backhaul predictable and avoid consuming wireless airtime for a mesh hop when Ethernet is available. Wireless meshing remains useful when cabling is impractical; it is simply not my first choice when I already have the option to wire the AP.

Client behavior still matters.

The infrastructure can advertise roaming capabilities and encourage transitions, but the client still participates in the decision. A phone or laptop can remain associated with a weaker AP longer than I would prefer.

That is why I do not treat a controller’s coverage visualization or client list as the final test.

The real test is the device in the location where the user actually needs it to work.

VLANs exposed discovery assumptions

Separating networks is easy until a device expects everything to live in the same broadcast domain.

Casting, AirPlay, printers, smart-home devices, and media applications may rely on discovery traffic that does not cross a routed boundary automatically.

Current UniFi documentation provides mDNS forwarding between selected networks when a UniFi gateway is doing that job. It also explicitly recommends limiting relaying to where it is needed instead of treating multicast discovery as a reason to flatten the segmentation model.

That matches the lesson I learned from the environment.

The useful question is not:

How do I make every device discover everything?

It is:

Which clients need to discover which services, and what is the narrowest policy that preserves that function?

That question turned VLANs from a diagram into an actual policy.

It also made discovery part of the test matrix instead of an afterthought.

A network can be correctly segmented and still fail the user requirement if a justified discovery path was never designed.

A small traffic matrix would have saved time

If I rebuilt the policy from zero, I would write this before creating the firewall exceptions:

Source role	Destination role	Need	Default decision	Validation
Guest	Homelab	None	Deny	Guest cannot reach lab test endpoint
IoT	Primary clients	Usually none	Deny	IoT client cannot initiate toward personal client
Primary clients	Selected IoT/media service	Discovery/control where justified	Narrow allow	Real casting/control workflow works
Work	Homelab	None unless explicitly required	Deny	Work client cannot reach lab management path
Primary clients	Homelab service	Specific application access	Allow only required service path	Real client completes application workflow

That table is illustrative rather than a dump of my live firewall rules.

Its value is that every exception has a purpose and a test.

Without that record, it is easy to look at an allow rule six months later and know what it does without remembering why it exists.

Visibility helped troubleshooting, but the dashboard is not proof

Centralized client, access-point, and network information makes it easier to answer basic questions:

Which access point is a device associated with?
Which network assigned its address?
Is the client wired or wireless?
Does the issue affect one device, one AP, or an entire VLAN?
Does observed policy behavior line up with the failure?
Did a recent configuration change happen near the beginning of the problem?

That visibility gives me a faster starting point than walking from device to device.

It is still a starting point.

A dashboard can report that a client is connected while the application the user cares about is broken. It can show the expected VLAN while DNS is wrong. It can show healthy AP status while one physical location still has poor RF conditions.

So I separate management-plane visibility from user-path validation.

The controller helps me form a hypothesis.

The client test tells me whether the requirement works.

What the platform abstracted—and why I accepted that tradeoff

An integrated interface necessarily hides some of the machinery behind a simpler workflow.

That can be a benefit and a cost.

The benefit is operational consistency. I can define networks, map Wi-Fi to those networks, inspect connected devices, and manage policy without stitching together a different control surface for every component.

The cost is that abstraction can tempt me to learn the interface instead of the networking underneath it.

I try to counter that by translating important configuration back into fundamentals:

Which VLAN is this traffic in?
Where does routing occur?
Which boundary evaluates the policy?
Which direction initiated the flow?
Is the issue Layer 2, Layer 3, DNS, discovery, RF, or application behavior?
What test proves the user path rather than merely the configuration screen?

If I cannot answer those questions, a polished dashboard has not taught me enough yet.

Why I did not build around used enterprise gear

Used enterprise switches and access points can provide excellent value.

They can also introduce licensing, controller, noise, power, support, and compatibility questions that vary dramatically by platform and generation.

I wanted the lab to teach networking without making basic household Wi-Fi depend on an ecosystem I was still learning to operate.

That was a personal operating constraint, not a universal criticism of enterprise gear.

For a dedicated networking lab, those same complications could be the whole reason to buy the equipment.

The important distinction is whether I am buying something to run the house or buying something to learn the platform.

Those can overlap, but they do not have to be the same purchase.

What UniFi did not solve for me

Centralized management did not design the trust model.

It did not decide which cross-network traffic was justified. It did not document why an exception existed. It did not prove that coverage was good from the devices that actually mattered. It did not make every IoT discovery protocol behave cleanly across routed boundaries. It did not eliminate the need to understand DNS, DHCP, switching, routing, firewall state, multicast, RF behavior, and client decisions.

Those remained design and operations problems.

The platform made them easier to express, observe, and revise.

That is different from solving them automatically.

When I would choose something else

A good decision record should include the conditions that would make the decision change.

I would reevaluate this choice if I needed capabilities that the platform could not provide cleanly, if licensing or product direction materially changed the ownership model, if the environment grew beyond the scale I was comfortable operating this way, or if I wanted the network itself to become the primary deep-dive learning project.

Likewise, a smaller environment that only needed reliable internet and uncomplicated Wi-Fi might not benefit enough from VLANs and policy tooling to justify the extra platform cost and complexity.

The right answer depends on the job.

That is the same purchasing principle I use in Buy Once, Cry Once, Sometimes: a more capable product is not automatically a more valuable product unless the capability serves a real requirement.

What I would do differently

I would document the intended traffic matrix before creating the VLANs.

It is easy to create network names and isolation rules. It is harder to remember why one exception exists months later.

I would also measure coverage before and after AP placement rather than treating a visually central mounting position as sufficient evidence. The user-path test should include the rooms and devices that actually matter, not only the AP status page.

Finally, I would preserve a small change record for network-policy modifications:

Change:
Reason:
Source role:
Destination role:
Required service/discovery:
Expected deny paths:
Validation performed:
Rollback:

That is more useful six months later than a screenshot of a firewall page.

Currentness note

This article was reviewed on September 14, 2026 against current Ubiquiti documentation for virtual networks/VLANs, network and client isolation, SSID-to-network assignment, mDNS forwarding, switch policy, and Wi-Fi behavior.

Current UniFi capabilities are broader than the specific functions I use in this decision record, and feature availability can depend on gateway, switch, AP, and UniFi Network versions. The article therefore focuses on the requirements and operating model rather than freezing one screenshot or menu layout into permanent instructions.

Key takeaways

Segmentation should follow trust and access requirements, not novelty.
Central management improves visibility but still requires networking fundamentals.
Wired AP uplinks are my preference when practical; wireless mesh remains a valid design tool when cabling is not available.
Discovery across VLANs should be allowed deliberately and narrowly.
A dashboard should support troubleshooting rather than replace a real client-path test.
UniFi fit my balance of capability, cost, learning value, and maintainability; it is not a universal enterprise replacement.
The strongest part of the decision is not the brand—it is knowing which requirements would cause me to choose differently.

References

Security and privacy note

This article describes the trust model and decision process without publishing the live network map. Exact equipment models, AP placement, SSID names, VLAN identifiers, subnets, firewall rules, addresses, device names, management endpoints, credentials, and work-network details are intentionally omitted or generalized.

AI transparency

AI assisted with organizing and editing the original article, the September 14 decision-matrix revision, technical cross-checking against current Ubiquiti documentation, and the publication privacy pass. The network-segmentation goals, multi-AP design, discovery issues, operating tradeoffs, and conclusions are based on my own home-network experience. The alternatives matrix is a decision framework rather than a claim that every product in a category has identical capabilities.