Since the data is user-specific, for your TODO-list example storing it in Sitecore items does not make sense and does not add value. It is important to have a clear separation between your business domain data (TODO items management) and content (localizable data you store in Sitecore).
There are several approaches for such cases:
Your Sitecore renderings can retrieve data from your custom database (of course it is advisable to abstract the storage via Repository/Service patterns, which you can inject into your rendering code), combine it with Sitecore content (if needed, e.g if your TODO items have some localizable content, like labels) and render it all together.
Alternatively, you can also build a Web API which will be responsible for providing data for your renderings. In this scenario, your frontend code will be responsible for calling this API. This ensures even higher degree of separation of your business domain data and Sitecore content. This can also lead to a broader discussion on where to store/host the business logic in your Sitecore projects, which is covered in this question: Sitecore helix pattern and where to place your business logic
Note: When building such kind of components which combine external data and Sitecore items it is also important to consider Experience Editor support. For example, you have to make sure that in Experience Editor mode you don't query data from your 3-rd party system, but you provide some mock data instead (because there is no authenticated user context and your Content Editors do not care about the data itself, they only care about content).