First, you should read through Gaffer on Games's article What every programmer needs to know about game networking. It covers all the important parts on typical networking architectures and their pros and cons. There's also some decent answers here: Limitations of p2p multiplayer games vs client-server. But basically you have two architectural choices: P2P or client/server¹. It's an important decision since it has huge consequences, like how well you can handle cheating, or compensate for latency, all of which depend on your game; there is no "right" choice.

The reason why you need to be aware of all this is that it also affects your choice on whether to build your game with networking in mind from the start, or build it in later:

• P2P is much easier to build later than client/server, especially if the game's architecture was not designed with clear separation of concerns from the start, like mixing game logic with rendering. As someone who's added client/server networking into such a game, I can attest to it being a huge amount of work.
• Client/server is harder to work with, especially if you are a small team. Any game feature might involve multiple decoupled systems, and additional decisions on how it will be handled: by the client, by the server, by both, and how. For programmers not familiar with this, it can slow down progress.
• However, for the most demanding networked games, client/server is pretty much mandatory, given the severe limitations of P2P.

This is all covered in the Gaffer on Games article I linked at the start. Here's the relevant real-life experience from id's Doom/Quake games:

• Doom came with P2P networking, which worked well on LANs but was unplayable for the typical online connections at the time (14.4Kbps modems).
• Quake was written as a pure client/server architecture from the start, and networking was trivial. Online multiplayer was playable but typical clients experienced so much latency that they had to suffer a degraded experience
• QuakeWorld, which included client-side prediction, meant that players with high latency can still play with a decent experience, and this model became the industry standard since

So what this all boils down to is four choices, ranked from easy to hard:

• Write game with P2P networking from the start
• Write game first, add P2P networking later
• Write game with client/server networking from the start
• Write game first, add client/server networking later

And with the following considerations:

• P2P is easier most of the time²
• Client/server is mandatory for online networking for certain genres (action, MMO)
• Writing with networking from the start is easier, and much easier if you choose to do client/server
• But keep in mind the caveat that game development is risky, so there's an advantage to making a game as fast as possible to test its viability

¹Note that when I say "client/server" I'm assuming you also do client-side prediction. Pure client/server, i.e. dumb clients, isn't too hard. Most of the difficulty comes from client-side prediction and how you reconcile client and server discrepancies.

²P2P can be harder if you want to handle things that it's not well-suited for, like drop-in/drop-out. But the "classical" P2P lockstep model as used by Doom is dead-easy, it simply requires sharing state across all the players.