When you simply want to write down a task
DevFlow Studio starts with an ordinary need: keeping tasks, projects, focus sessions and a technical journal together. When an idea arrives or work resumes, I want the context nearby. An organisation tool already asks for effort. Its first useful action should not depend on a step that has not yet helped someone do the work.
The workspace therefore uses IndexedDB with Dexie for its main data. It starts in the browser, so the application can be useful before an account is created. This decision reaches further than the sign-in screen: it defines where the product reads its state and what role remote services can take on later.
Give the data a clear home
A task is more than a row on a screen. It belongs to a project, has a status and can appear in several views. DevFlow brings together Today, tasks, projects, focus, the journal and reviews. If those screens disagree, a richer interface only gives someone more places to become uncertain about the same piece of work.
I treat local storage as the workspace reference rather than a temporary copy of a remote server. Typed models, validation and tests help keep those relationships understandable. They also raise practical questions about transitions: what needs to remain consistent when a task moves to another project or changes status, for example?
The cloud needs an explicit agreement
Supabase provides foundations for optional identity and workspace capabilities. That does not mean tasks or journal entries are automatically synchronised. Mixing those ideas would make the product difficult to explain. Someone should not have to guess where their work lives after signing in or whether an optional service has changed the local workflow.
Future synchronisation would need clear rules. Imagine editing the same task on two devices: which version should remain, how should a conflict appear and how could a silent loss be avoided? These are design questions still to address, rather than completed capabilities. Adding an account would not, by itself, answer them.
Local storage is only part of keeping data safe
After several weeks of work, the data matters. Changes to its structure, import, export and recovery then deserve attention. Recovery tools belong to the project, but storing something locally should not be confused with a guarantee of preservation. A place to keep data is only one part of a backup and recovery approach.
One useful hypothetical check would start with a representative workspace, export it and inspect what an import restores. Relationships between tasks and projects matter as much as row counts. A migration raises a similar question: can someone recover both the information and the meaning it had before the structure changed?
Keep the product’s promises within reach
DevFlow remains in active development. The planning assistant, local insights and daily views need to serve the same purpose: making work easier to resume. A feature can look appealing in isolation while complicating that path. Its cost includes the models, screens and checks it adds, as well as the demonstration that first made it attractive.
My next priority is to strengthen those workflows and the boundary between local storage and optional services. Starting locally gives the product a direction, along with concrete obligations. The approach makes sense when people can understand what is saved, what can be recovered and what is not yet shared between devices.