Many people do use WordPress for big commercial sites, because it's a solid platform - but partly because of its popularity, is it also something of a magnet for attackers. It is vitally important to make sure you keep it up to date, and use something like then WordFence plugin to alert you to anything unexpected happening - it can lock out IP addresses, for example, or particular users, based on failed login attempts.
If you do develop from scratch, then what you use to do that is up to you - I'd use PHP, because that's what I'm familiar with, but others have their own preferences, and even for particular frameworks within those languages. Most important, whatever you use - code defensively, treat every bit of data received from users as potentially dangerous; check it's the right type, or an allowed value, etc, before it goes anywhere near a database.
In terms of protecting customer data, if you're going to be dealing with customers in the EU, read up on the GDPR (which in any event, is probably a good set of guidelines wherever you are, if you actually care about customers) -
http://www.eugdpr.org/
Back end, front end, full stack - up to you, but I tend to the view that the full range of technologies involved these days is so broad that, unless it's a pretty small operation, you really do need specalists for each bit, rather than one person expected to do the whole thing. The skills to make something look decent, and a web site responsive, are not the same skills as those to design an SQL database structure, or to code in PHP, B4X, or to optimise Apache to handle the number of clients, or keep abreast of which libraries you need to update on your server to ensure that SSL connections really are secure.
One other thing I'd say - before you start coding back end or front end, design your database first. Think about what information has to be stored, and how it will be accessed, and how you might perhaps want to access it later, or what sort of updates might be needed. Work out what tables you need, and how they relate to one another, and consider the impact on the design of the queries you'll be running. It's tempting to just throw new tables into a database as you go along, and decide you want a new feature. The danger of that, though, is that in a few years time, you realise you want to do something else, and suddenly ad-hoc way your data has been organised means mind-bending SQL queries that gobble up processing time, and and developers ending up jumping through hoops to get the information they need, or keeping information up to date is more complex than it would have been if you'd designed things differently.