I’m a network engineer in my day job, have two school age kids, I volunteer for my kids scouting troop and have many hobbies (astronomy, electronics, gaming, home server lab to name a few) and I always added tasks faster than I can finish them. I started writing projects and tasks on paper, which quickly became unsustainable. I could see everything ongoing at a glance, but it became useless as I complete and add tasks. Eventually I decided to try some of the popular apps.

Many apps are great at what they do, but I just couldn't find one that fit my needs. Some were based on Kanban/Scrum like approach and I really didn’t want something that reminded me of my day job in my free time. Some would not let me create tasks without due dates. I do my personal projects whenever I have free time, not on a fixed schedule . Others had platform limitations, missing web or mobile app, and some did not let family members create their own projects unless they have their own subscription. I eventually settled on one, decided to write a middleware that would read tasks with API, calculate a completion percentage for each project, generate and upload a status image to Amazon photo gallery to show as slideshow on Echo Show screen. The goal was to keep an eye on what projects I am closer to finishing and which tasks are my next goals. It felt like trying to fit a square into a round hole with an app that wasn't designed for how I think. I decided to ditch the whole middleware approach and started building something I truly wanted to use.

I started with a working title of calmprogress. I aimed for an app where every field except name is optional, and no overdues. Everything that would normally be past due is simply due until done, and ongoing is a valid state. For me and I think for many others, red past due warnings are only a cause for anxiety which leads to procrastination, so I skipped red text (except for very few irreversible actions) completely. Smart Home integrations, no platform lock in, open API, access for whole family as first class users (all family members can create their own tasks, separate from the account holder), offline first with online sync were non negotiables. Making progress towards goals while not causing distress is the main goal of the app, so I decided on the final name of ProgressCove.

Architecture Choices

Backend: Python FastAPI was an easy decision, since an open and accessible API was a nonnegotiable of this project. Nginx proxy to accept connections, PostgreSQL with PgBouncer on a Hetzner VPS. Database is backed up to separate attached disk and periodically dumped, encrypted and backed up off cloud. Everything is built with containers, so I can scale it up without too much trouble. I started with one proxy VPS and one backend VPS and Mikrotik CHR to secure all traffic from proxy to the backend. I was spreading the load across more VPS, prices increased by 300% around this time, so I decided to leave most of it consolidated on a shared VPS until user base growth calls for the expansion.

Frontend: All logic, including smart features of the apps run on the server. The only way to read data from the server is through the API. This allows me to host a lightweight React web app on a Cloudflare worker for the web app. Mobile apps use React Native with Expo. This keeps adding features to both web and mobile versions relatively simple.

AI coding without the slop: I could eventually write everything by hand, but it would take significantly longer. It does not make sense to penalize myself for pride; I used Claude Code to write the code while I provided heavy guidance. If you let Claude write your whole codebase without oversight, it’s more than happy to write 80+ lines of useEffect hooks you can get lost in and throw a single page into a single file instead of breaking into reusable components, negating biggest advantages of React. I followed an iterative process, where I write requirements and explain details such as expected classes, attributes, objects, let Claude write the initial version, then go over it and fine tune, telling Claude exactly what needs to be changed. Once that’s done, then have it write tests, do a security review, and adversarial review where it hands it off to several sub agents to find exploits.

Offline first, PIN protected databases for the whole family: Since offline usage is a must, I used WatermelonDB for mobile app versions to store data locally, with a sync function triggered automatically on save and periodically on a timer to the server, and SSE triggered from the server, as long as there’s internet connection. To keep data secure for family devices, each user gets their own PIN protected database. When a different user is selected, app will ask for the user’s PIN, relaunch the app with that user’s database, and lock switching back to the account holder with their PIN. Database picking is limited to app launch, which helps avoid most user/database selection type of bugs. Current family implementation gives only the account holder log in credentials, so account holder needs to log in and switch to the user to give family members their own app installation. I am working on a family based log in system, so all family members can log in directly. Sharing anything with family is already in the app, and with this family log in implementation, task assignments will be added as well.

How to write for different platforms while keeping it sustainable: Flow of the app logic is always same regardless of platform. For example, non mobile clients & integrations follow same sync model as mobile, but they assume always online and skip the code components that write to offline database and sync immediately. I also avoided mixing platform specific code and shared code, which allowed me to minimize the former as much as possible. Keeping all code blocks like lego pieces in the monorepo, I could impor only the relevant blocks for the platform. So far, I have released Android, iOS (and their Widget & Speech integrations, having Google or Siri add your tasks) and Web app from this monorepo and a Home Assistant integration from a separate repo, since it uses MIT license and is fully open. Echo Show and Google Home integrations are on the way, and anyone can write their own for any platform if they desire. (I still need to write and host API documentation, but no additional work required to make it available to everyone, and one could easily figure it out from Home Assistant Integration code).

A contract file is also shared across different platforms, which contains value limits accepted by the API. Clients will check the contract to ensure they send correctly shaped and sized data, but server does not blindly trust the client and also does its own checks on incoming data.

Continued on first reply