A Scrum project starts with the first sprint. In order to start the first sprint, you will need a team and a backlog. The backlog is the easy part, most teams can start the first sprint with some random notes scribbled on a napkin if they need to. Assembling the team is usually the hard part unless you already have a team.
Scrum doesn't tell you how to gather a team or obtain your starting backlog. Having them is essentially one of the requirements of doing Scrum. Essentially this is like a recipe; the recipe to bake an apple pie will tell you that you need to have apples. It doesn't tell you where to get them, and it doesn't care if you bought them in a supermarket or picked them from your own tree. The recipe merely requires you to have them, because it deals with how you use the apples and not where you find them.
Scrum is designed as a recipe for turning your team and your backlog into a working product, but getting the ingredients is not part of what Scrum offers. These are business decisions. Scrum is not a guide for how to run your entire business.
Answering your specific questions:
When do we gather the team?
Before you start doing Scrum, because a team is one of the requirements for starting Scrum.
Should the product backlog be ready before we start? If the product backlog is not ready before the start, then we can't prioritize it and choose the things to be done first.
It should be "ready" in the sense that it contains enough information to get started. For many teams, notes from the original meeting with the client is enough to get started. Expanding the backlog will be one of the things taking up time during the first few sprints.
What should be done first and who needs to be involved?
Get the whole team together, grab the backlog and start the first sprint with a sprint planning meeting.
I'll also add in some of your questions from comments, since the answers to those mostly align with what I stated above.
When do we learn what technology stack we are gonna use?
At the very latest, during the very first sprint meeting, when the team decides on how they're going to turn backlog items into a working product. Practically, this is often decided beforehand. It could be the company ("We're a Java software company, so your tool is Java") or the customer ("I need this app that works for all my employees and we give all of them Android devices")
But if neither of those have a strong opinion, the team will decide based on what they think the best way to tackle the backlog is.
When do we determine what developers we need?
Before you start doing Scrum, because the developers are part of the team and the team is needed to start Scrum. Determining which developers you want to get into your team is a business decision and Scrum will offer no real help. (Beyond stating that whomever you hire, the whole group needs to have all the skills to handle the project. Knowing when they do is tricky before you start, but it's more a general "three developers who can't design an interface is not a complete scrum team" rule)
But what the team is gonna do if they have only epics at the beginning?
Decompose the backlog into smaller stories and then work on those.