Are using website builder's, like Squarespace, generally safe to use
"Safe"? Safe from what? That's a word with no meaning unless you elaborate what it is that you'd consider to be "not safe". Wasted hours? Limited design freedom? Licensing cost? Future-proofing? Bespokeness of the end product? Learning curve? Documentation reading effort? Documentation writing effort? Onboarding new people onto the project? ... (I can keep going)
I could apply the same level of effort I am now, but using a web-builder, and would effectively wind up with my screens AND the HTML/Javascript IP. At face-value it seems like a good win for efficiency.
This is a different way of saying
I don't need to figure out where I'm going right now, I just need to start driving and I'll figure it out on the road.
Which is trivializing one of the major complexities of development. You are assuming that when you are in the midst of technically building your components (whether this is building from scratch or configuring existing templates is an irrelevant distinction) that you will still be able to fully focus on freely making design decisions; and if you change your mind mid-way, that any change you'd make visually would be equally simple to execute in the technical component itself.
Neither of these statements are realistic estimates of the technical work required here. I'm not saying it's impossible, but doing doing two things at the same time has the equivalent complexity of doing three things separately. In your mind, you're thinking of how many straws you will indeed have to transport, but you're ignoring how strong the camel's back is.
That said, I know these builders don't support everything
I'll rephrase that from the POV of a technical person:
I will have to deal with inherent limitations in achieving my designs, and I'll either have to adjust/abandon my designs when this happens, or spend more time figuring out a clever way to achieve my goals anyway.
This is referring back to the "changing your mind mid-way" point I made earlier. Yeah, it's nigh impossible to get it right the first time and you will need to adjust mid-way, but be very careful about the amount of effort that this is going to entail if you're trying to design and build the application at the same time.
But I don't know 100% as I also have learnt that it is possible to obtain the raw code for your website.
Having the code and making sense of it are two very, very different things.
I cannot stress enough how different they are. A significant subset of developers have built entire careers on the skill of being able to take undocumented code and somehow revive it into a living codebase, and even the experts can barely keep such a project on life support (without refactoring to the point that it counts as rebuilding it from the ground up).
This is already true of a bespoke application that matches your specific requirements, let alone you thinking of doing this with a templated web builder.
Templated web builders add significant layers of abstractions specifically because they have to build components that work for everyone's use case, not just yours. When done well, you don't notice it in the frontend, but the code is a very different topic.
I'm hammering this point home because I want to contrast it to something else you said:
At face-value it seems like a good win for efficiency.
Try justifying your "I get the raw code, I take it from there" approach with efficiency. It's multiple orders of magnitude more inefficient than needing to do a UI design and technical build in two steps; and the fact that you don't see this is worrying for the technical direction this project is going in.
Based on your proposed solutions, I genuinely believe that you do not have the experience of building anything technical behind you; while at the same time trying to improve on and find shortcuts in the technical work before you.
Please feel free to ask for clarification if my question is too high level
Your question is too high level, but not in the way you intended (i.e. possibly needing to clarify further details in your posted question). You're making high level decisions about lower level implementations without any experience with actually executing the lower level.
I can tell that you did take some stabs at technical research, which is good; but you're running with what is a very crude and rudimentary understanding, running with it as if it's an expert opinion that has exhaustively considered all the ins and outs of the options you're considering, and then trying to apply it in a different from the tried and true development path (e.g. you know about making UI mockups before developing, but then you subvert it into a clever effort-saving trick to not do it).
Long term, even putting this specific question aside, I am concerned about the road you are leading this project down.
If this project is a business venture, I very strongly suggest you onboard a technical person to sanity check the work that you're trying to perform (and just have them do the work for you instead). Don't try to be your own dentist. It's not going to end well.
For this specific question, it's irrelevant to the larger issue. Build vs buy has tradeoffs that mostly depend on the freedom of your designs and the complexity of the building stage; but they are eclipsed by the kinds of problems you're thinking of (unwittingly) introducing to the project, based on things you've mentioned in this question (let alone any other ideas you might be having which didn't seem on-topic to bring up for this question).
Really reconsider if you're making informed decisions here, because I'm not convinced you are.
