Hi everyone,
I have spent the last 6 months on learning Playwright/TS from various courses and websites. The project I work on currently does not have automation involved at all. I will be writing the first tests. The developers have already written Integration and Unit tests.
Where do I start is my main questions?
You start by figuring out critical components/modules of your project.
Are there any areas which are mature enough to not be influenced by any changes in near future and testing them seems to be a repetitive task?
If yes, would it be of any value to automate them?
If yes then go ahead 
I personally would focus first on getting fast feedback. Trying to get a couple of tests running in your current CI process.
What to automate will come down to a lot of factors. You likely already know the areas in your application that cause the most problems or are critical for business.
What are the goals of your first tests that would make their goals slightly different from later tests?
Here are a couple of early goals I used recently for example. Yours may be very different.
A simple navigation test, open app, navigate between views will often suffice provided it is pulling displayed data from the backend.
This step can take time and may need developer help but I still feel its worth starting on straight away so that then you can focus on scripting.
2a) Common code that will be used in a lot of tests. Different frameworks use different language but sometimes this is the before each step, tear downs or general help files with common code.
2b) I want my first tests to show examples of good coding practices, extraction, re-usability, not confidential data within actual test.
login and out test was often useful here. The code is often likely to be used in other tests or at least setting a logged in state. So you may write the test as script but then extract out most of it into common files for re-use. You will also likely look at passing in passwords to the script, that process can set the example practice for other variables and not just confidential ones.
We ended up 6 or 7 key users flows for this.
When 1, 2 and 3 were done and importantly very stable, consistently passing we then looked at process and practice to get it part of business as usual.
The above was fairly quick as it was a small product but its actually quite a lot covered to get to the point that after this the focus can primarily on scripting and expanding coverage.
Iโve used that approach on a few projects, we learn something new every time but still questions. Does it work, are we building it right and is it useful can be answered fairly quickly.
I always start with core user flow - the one that is the most important from business perspective. For example, in an eCommerce app, that would be ability for an end user (customer) to register/login and successfully make an purchase.
Once you cover that core flow with automated tests, you just keep adding more tests for other app areas by priority (how critical they are for end users).
Also, some things are probably not worth bothering with, unless you have plenty of slack time. Like static pages (ToS, About, etc.).
This is perfect. Show the stakeholders, the approach works, and more important, you can get a fast feedback.
my simple answer would be this:
Congrats on starting with Playwright/TS! Here are some steps to get you going:
I hope so this information helps you. great work