> They already have a WordPress/Woocommerce solution that is slow and very inflexible for what they need.
I concur with the other poster that it's probably easier/safer to fix and/or extend the Woocommerce with additional functionality than to try to reinvent the wheel from scratch. Wordpress/PHP is pretty extensible and can be made performant with good caching.
Probably moving it to a better Wordpress host like Pantheon or WPEngine would speed it up with minimal effort (but possibly high hosting costs, which are usually still cheaper than dev time).
Depending on what additional flexibility you need, you might be able to write plugins to add just that functionality while keeping the basic ecommerce stuff in the core?
> Good thing is I will not be hiring any developers, the plan is to hire a development firm that will build out the website.
It would probably help if the agency has prior ecommerce experience with a popular stack. It doesn't have to be Woocommerce or Shopify specifically, but I'd stay away from something totally custom unless you absolutely have to. A commodity stack is a lot easier to maintain over time and to find people to work on later if they need to add additional features. Even something no-code/low-code like Wix/SquareSpace/Square these days has ecommerce built-in, and that's a heck lot less work than building a web app from scratch with no experience. At the very least, you should outsource payment processing at least, like to Stripe or others, instead of processing your own credit card payments using custom software (PCI compliance is hard and it's easy to accidentally create vulnerabilities)... you should never know your customers' credit card numbers if you can help it.
If I were doing this, I'd really look at the business (profit margins, how they handle orders and shipping and refunds and all that), who's on the dev team both now and for the foreseeable future, etc.
It basically comes down to how much staff the business wants to keep over time to maintain this thing in-house, vs outsourcing as much of possible to a specialized vendor that they can just have a contractual relationship with.
From one techie to another, this is the sort of thing any of us can build with some time and research, but that's the sort of project that can too easily backfire and end up creating a lot of tech debt for your client (your friend) if nobody else can easily maintain it later.
If your client uses a run of the mill Woocommerce setup, after you leave they can easily hire any ol' Wordpress dev for a few days to fix whatever comes up. That might cost a few hundred dollars.
But if you make something completely custom for them using a nonstandard stack, suddenly it's a multi-month affair for a much more experienced (and expensive) dev to come in and reverse engineer your whole stack and learn to extend it, only to extend it with their own nonstandard way. Suddenly this simple ecommerce site is now a full-blown web app requiring a whole team of specialists to maintain. Now it's several tens of thousands of dollars. It's not good for most small businesses to have to deal with something like that.
IMHO a commodity online shop shouldn't be a fancy vanity project; it should be simple and reliable and predictable and require the least amount of ongoing maintenance possible.
> Thanks for the info on the intricacies, do you have any resources that can help me out with those?
Sorry, I'm not the best person to ask that of :( I've mostly just learned through accumulated experience working on ecommerce and other sites.
I bet these days there are good online tutorials or YouTube videos to get you started, but an ecommerce shop is such a broad (if relatively shallow) app that it's hard to get it all right. It really depends on the level of functionality, security, etc. that you need, and at what budget, with what staff/expertise availabile.
At the simplest level, if you can outsource all actual order management and fulfillment to a third party (like Amazon or Shopify or whatever), you basically end up just creating a bunch of mostly static product pages that pulls pricing and order data from an API. That's not so bad since all the critical stuff is handled elsewhere.
But the moment you need to start maintaining your own databases for all that stuff, it can get a lot more complicated really quickly.
There are also partially-vendored solutions like CommerceLayer or Commerce.js that do some of the heavy lifting for you to add a simple frontend on top of, or old-school PHP monoliths like Magento (now owned by Adobe, apparently).
I don't know if you can afford this, but it might help to look at some high-level (abstract) ecommerce UX, like from the UX group NN: https://www.nngroup.com/reports/ecommerce-user-experience/ This discusses many of the user-facing concerns that you can think about whether you need to build. If you don't want to buy the report, you can also browse through their free articles and videos: https://www.nngroup.com/topic/e-commerce/. That just discusses the UX though and not so much the "how to build it" part.
If you've never done web dev before, some random keywords you can look into for an idea of what you might have to deal with are: payment gateways/hosted checkouts, iframes, CORS, TLS/HTTPS, PCI, AJAX, ACID, accessibility, internationalization, CDNs, responsiveness, dev/staging envs (or CI/CD for something more enterprise-y), network stuff (DNS, hosting, caching, load balancers if you get a lot of traffic), SEO, forms & validations & sanitization, roles & permissions & session management, LEMP vs Jamstack, CRM, transactional emails, SPF/DKIM/DMARC (email deliverability)... that's probably a good start? None of those topics are individually very difficult, it's just that there's so many of them to juggle together to make a basic, functional ecommerce solution :(