To recap, the requirements I set for this systems are the following:

  1. Be digital.
  2. Support multiple devices and syncing.
  3. Allow the user to remain in full control of their data.
  4. Be easy to set up.

Being Digital

In order to tackle requirements 2 and 3, requirement 1 will have to be fulfilled. In other words, the system will have to be bundled into an app. As most people already have their phones on them at all times, there is no more convenient option than just using an app and not needing to bring any additional equipment with oneself on the go.

Multi-device Support

For the app to have multi-device support (first part of requirement 2), I could create 3-4 different native implementations for each type of device, but that would be far too much work. Instead, using a cross-platform framework of some kind would be more ideal. After some research, my options are the following:

  • Create a web app using a JavaScript framework (React, Vue) then turn it into mobile app using Electron or Capacitor.
  • Use a cross-platform framework like Flutter or React Native.

Since I’ve previously built applications with Flutter before, I will be using it as my framework of choice. However, my previous applications were quite simple in comparison with what I’m trying to achieve with this project, therefore I will be making several sub-projects to get the hang of it in the process.

However, going with Flutter has a downside that may affect the third requirement: telemetry. As Google is the main creator of Flutter, there may be some hidden telemetry baked into Flutter, causing the users’ data to be slightly compromised. Despite this, I believe I will still have to stick with Flutter, as using any alternative approach would slow down the development process. I will however manually disable as much telemetry as I can.


As for the second part of requirement 2, that is, data syncing, there are two options:

  1. Using a peer-to-peer synchronization system like Syncthing.
  2. Using a cloud-hosted server to host a database, which is where the data will be stored.

Here are some pros and cons of each.

P2P (Peer-to-Peer) synchronization system


  • No server required = No extra costs
  • No authentication required.
    • As you have to manually connect your devices to one another directly, there is nearly no risk of someone stealing your data as all of it is stored solely on devices you own, and none of them require access to the internet to synchronize.


  • Connecting each device you have to each other will be tedious for the setup process.
  • Implementation will be quite difficult.
  • Conflict resolving may be common = worse ease of use
    • For example, you have two devices which are unable to sync with each other, but edit the same file on each of them. Then, sync the two devices. The two devices will have two files that were edited since they were last connected and do not know which one is the correct file.
  • No redundancy.
    • For example, you left the house for a work trip with just your phone, but a week into your trip, your phone’s storage gets corrupted. All the data you entered during the first week of the trip is now permanently gone.

Server system


  • Redundancy.
    • As all the data on any one device is kept in sync with the server, if the device fails, fetching the data from the server should restore what was lost.
  • Simpler device-side setup.
    • Ideally, it will just be putting in the IP address (or domain name) of the server and authenticating yourself, and everything should be synced.
  • Implementation may be simple.
    • There are several server database solutions available already with good documentation, and some even have specific guides for use with Flutter.
  • Flexibility.
    • With a server, additional features become feasible. For example, multi-user support, which I plan to do as implementing authentication is already required for this implementation.


  • Cost.
    • An external server will be required. If using a low-cost VPS (Virtual Private Server), the costs may be about 4-5 euros a month.
  • Potentially complex server-side setup.
    • There will likely be additional complexity from needing to set up the server securely, as the server is accessible by anyone on the internet.


Based on the list above, I have decided to use a server-based setup, with the main convincing points being redundancy and flexibility. I feel like I can justify the cons with the following:

  • Cost
    • Many current free digital productivity systems have catches to prevent abuse of their systems, and they make users pay for either higher limits or additional functionalities (like syncing). The same amount of money in their paid tiers tends to be enough to afford a low-cost VPS.
  • Potentially complex server-side setup.
    • As this system is intended for my personal use, I personally don’t mind the additional tinkering to get things up and running. However, if there is a future demand for it, I believe creating a script for a very quick setup experience on the server could be achievable. For example, something like the Pterodactyl setup script, which drastically simplifies the setup for Pterodactyl.

Server Database

As using a server as a database is actually fairly common, there are ready-made solutions that are open-source. I previously hinted at this previously:

There are several server database solutions available already with good documentation, and some even have specific guides for use with Flutter.

Some may have heard of Google’s Firebase, which I have used before. However, there are actually a fair amount of alternatives, and given Google’s track record with telemetry, I think it’d be wise to use something else.

Here’s what I found:

  • Pocketbase
    • Pros:
      • One file, very simple.
    • Cons:
      • Uses sqlite in the background, may not be the most performant.
  • Supabase
    • Pros:
      • Scales up very well.
    • Cons:
      • More complex.

I decided to try out Pocketbase because:

  • Simple is best. I want to focus more of my time on creating good user-side applications and less time debugging the server-related code.
  • This system is intended for a very small group of people to use (1 person ideally, maybe 5-10 people max), which means the scalability of Supabase will likely not be very useful.
  • After checking out some benchmarks for Pocketbase, it seems that creating thousands of posts will only take a few seconds, which is more than any individual (or small group of individuals) will need.


  • App framework: Flutter
  • Multi-device support implementation: Server
    • Server database (backend): Pocketbase