It's all going to come down to what you're trying to do and how you're trying to do it. You identified the questions, what are your answers to them based on the website or app? Because even the question as to website or app is going to be different by itself. Are you trying to custody funds or are you trying to be non-custodial?

It's getting to the point that lightning has created an entire ecosystem, it's like asking "what's the best database to use at a startup?"

if you ever in Austin come to PlebLab we help with stuff like this, we have also been providing weekend workshops on how to implement lightning into a web stack, check it out here: https://www.youtube.com/channel/UCoUUXOdWNOSv_MTtYXMUwDA

also our friends at bolt.fun has some great documentation as well.

I feel like I'm making a "Senior Engineer meme" out of myself by saying "it depends".

Remember that a custodial lightning service is a financial service. You should expect to treat it with the same type of diligence that you would treat building the backend of a bank. In all honesty, I would suggest not doing it unless you are very confident in multi-layered security models and also uptime resiliency (if your server goes down, do people lose access to their money?).

Since you are a capable frontend dev, I'd suggest taking a look at WebLN: https://www.webln.guide/introduction/readme - it will allow you to offload the lightning backend to services listed on https://www.webln.guide/ressources/webln-providers. That way you can facilitate payments without having to touch the backend stuff.