I was trying to figure out whether a small NAS build had enough room to grow. The board had slots, which made it look flexible, but that is always the trap. Slot count is not lane count. A board can have a full-length slot that is electrically x4. It can have M.2, SATA, a NIC, and a second PCIe slot all hanging off the chipset. It can also have slots that technically exist but are not useful for what I actually want to do.
The real question was not, “How many cards can I physically plug in?” It was, “What can I plug in without creating a dumb bottleneck or blocking the next thing I know I will want?” For this build that meant onboard SATA for the first drives, maybe a 5Gb NIC, maybe an HBA later, and maybe a GPU if I wanted transcoding. All of those sound small until they start fighting over the same few lanes.
What helped was going lane based instead of slot based. CPU lanes first. Then chipset lanes. Then anything already consuming those lanes before I add a card. The manual block diagram mattered more than the product page. The marketing page made the board look like it had expansion. The manual showed what was actually wired.
The surprise was that starting simple was probably smarter. Four drives on onboard SATA did not automatically mean I was doing something wrong. If the NAS starts as a basic mirrored or pooled setup, onboard SATA is fine. I do not need to buy an HBA just because server people like HBAs. But I do need to know what happens later if I want more drives or a GPU.
The note for next time is to draw the lane map before picking parts. Not a fancy diagram. Just enough to answer: what is CPU attached, what is chipset attached, what shares bandwidth, and what am I saving for later. Useful beats elegant. A bad lane plan is one of those problems that feels like a software issue later, but it was really a parts decision made too early.