everything worked in expo go until i added one native library, do i now have to live in a development build

It is a permanent change and it is the normal way to work, not a punishment. Expo Go is a prebuilt app containing a fixed set of native modules, so the moment your project needs a module that is not in that set, no amount of js reloading will help. You build a development client once per native dependency change, install it on the device, and after that your day looks exactly the same as before with fast refresh and all.

Because you are on Windows, one thing worth knowing early: you can build the Android development client locally with the android toolchain and skip the queue entirely, and you cannot do the same for iOS without a mac. So the sensible split is local android dev builds for iteration and remote builds for iOS and for anything you distribute. That alone stopped me running out of the free allowance.

Mild pushback on the enthusiasm for dev clients as a lifestyle. If your app genuinely only needs modules that ship in the SDK, staying on Expo Go is faster and simpler and you should not move just because a thread told you to. Check whether the scanning functionality you need exists in the SDK first, because there is a decent chance you added a third party lib for something already supported, and then you have taken on a rebuild cycle for nothing.

Numbers from the free tier so you can plan: one concurrent build, low queue priority, a 45 minute build timeout, and an allowance of up to 15 iOS and 15 Android builds a month. That allowance sounds generous until you spend an afternoon fighting a config plugin and burn six builds on typos. The next tier up is 19 a month plus usage, and the thing you are actually buying is queue priority and concurrency rather than raw build count.

Install the dev client on a real device rather than only the simulator, from day one. Half the native module bugs you are about to meet only exist on hardware, and finding that out at release time is worse.