Concurrent programming isn't all "jump off a cliff into the atomic<T> and mutex lock sea and worry about deadlock or run everything in serial".
There is a middle ground where you take apart the easily discretized parts of your task at hand, that have little or no communication between them, and thread those. For example, if you have a system to scrape a user profile, processing the personal information, hobbies, and pictures in separate threads only requires sending work to threads in a thread pool saying scrape X. That X gets scraped, database calls are asynchronous and work up to the thousands of workers, and you don't even need to wait - pass off the profile, let the threads run and wait for a new connection.
Threaded parallelism only becomes dangerous when you start using shared data. That is where you need to ask if its worth the cost. You shouldn't be afraid of threading entirely just because you can back yourself into deadlock hell if you don't plan ahead.