LocalLifeOS

Inspiration

Life decisions rarely belong to a single app. Saying yes to a conference, buying a new laptop, or starting an ambitious project can affect a calendar, a task list, a budget, and a savings goal at the same time. Yet most personal tools show only one part of that decision. They help us record a commitment after we make it, but they do not help us understand whether it actually fits.

We wanted to build the missing layer between those tools: a private place where a person can see the real consequences of a decision before accepting it. Just as importantly, we wanted those answers to remain understandable and under the user's control. That led us to a fully local, deterministic product with explicit assumptions instead of a cloud account, an opaque score, or an AI making choices on the user's behalf.

What it does

LocalLife OS brings tasks, projects, calendar events, notes, finances, goals, and commitments into one local workspace. Its commitment engine connects the records involved in a decision and reports time capacity, financial capacity, dependencies, scheduling conflicts, goal impact, and deadline risk as separate, explainable results. Every warning identifies the records and assumptions behind it.

Users can ask LocalLife OS to suggest a schedule, review every proposed placement, and choose whether to apply it. They can also compare two or three what-if scenarios—such as attending an event in person, joining remotely, or skipping it—without changing their real data. Accepting a scenario shows the exact before-and-after changes and applies them atomically only if the source data has not changed.

The application also includes Markdown notes and backlinks, calendar and bank-file imports, multi-currency finance without hidden conversion, local automation rules, a unified timeline, offline application-shell support, and optional encrypted backups. It needs no account, API key, remote database, telemetry service, external asset, or runtime AI request.

How we built it

LocalLife OS is a TypeScript and Python monorepo. The interface is built with Next.js, React, TanStack Query, and Zustand. A typed FastAPI service uses Pydantic, SQLModel, Alembic, and SQLite, with an OpenAPI-generated contract connecting the frontend and backend. OR-Tools CP-SAT powers the bounded scheduling engine, while SQLite FTS5 provides local note search.

We kept complex rules in domain services rather than route handlers. Scheduling and scenario workflows use a preview/review/apply boundary with optimistic revisions and fingerprints, so a stale proposal cannot silently overwrite newer work. Attachments, imports, backups, and runtime state are confined to a local data directory. The browser caches only the application shell and static assets; API data remains network-only on the local loopback connection.

Docker Compose provides the reproducible judge environment, while PowerShell and POSIX launchers support native use. The final verification suite covers migrations, domain behavior, concurrency, timezone and currency rules, unsafe paths, import limits, backup tampering, offline behavior, performance, and the critical browser flow across desktop, tablet, and compact layouts.

Challenges we ran into

The hardest challenge was not building each feature independently; it was preserving meaning when the features met. A scheduled task can affect a commitment, a calendar conflict, a scenario, and a timeline at once. We had to define clear ownership and transaction boundaries so those views stayed consistent without duplicating mutable state.

Explainability also required discipline. It would have been easy to collapse everything into a single “good” or “bad” score. Instead, we built typed evidence and component calculations so users can see whether a warning comes from missing time, a dependency, a buffer-aware calendar conflict, or money in a particular currency.

Timezones, daylight-saving transitions, recurring records, minor-unit currency arithmetic, and safe file handling created many less-visible edge cases. The local-only requirement added another constraint: offline behavior, fonts, assets, telemetry, networking, and container configuration all had to be audited so the product did not quietly depend on the internet. End-to-end testing exposed a particularly subtle issue where a Docker-served Next.js development shell returned HTTP 200 but could not hydrate reliably offline; switching the image to an optimized production build fixed the root cause.

Accomplishments that we're proud of

We are proud that LocalLife OS feels like one coherent system rather than a collection of demo screens. A user can load a deterministic scenario, inspect a commitment, trace its warnings to real records, compare alternatives, preview a feasible schedule, apply a reviewed plan, and see the result reflected across the calendar, tasks, finances, goals, and timeline.

We also preserved user agency throughout the product. Assessments are explainable, previews do not mutate data, consequential changes require confirmation, concurrency conflicts are detected, and the workspace remains useful without sending personal information anywhere. The final review passed 82 backend tests, 31 frontend tests, all 39 browser route checks, strict type and lint checks, fresh migrations, encrypted backup/restore smoke tests, and the isolated Docker workflow.

What we learned

We learned that personal productivity is fundamentally a relationship problem. Tasks, time, money, and goals become much more useful when the links between them are first-class data rather than labels that only a person can remember.

We also learned that deterministic software can still feel intelligent. Clear constraints, traceable evidence, bounded optimization, and reversible scenarios produced useful guidance without pretending to predict a person's future. Privacy was not a final security setting; it shaped the architecture, feature boundaries, tests, and even the wording of the product from the beginning.

Finally, preview-before-apply proved valuable far beyond scheduling. It became a general design pattern for imports, scenarios, restore operations, and any workflow where the user should be able to inspect consequences before changing primary data.

What's next for LocalLifeOS

The next step is to package LocalLife OS as a signed desktop application around the existing local services, making installation and updates simpler without giving up the offline-authoritative workspace. We also want to design opt-in encryption for live data, including recovery and key management, before claiming full at-rest protection.

Product work will focus on broader CSV and ICS compatibility, richer but still explainable scenario templates, improved reports, and a dedicated detail experience for every linked entity. Quality work will expand screen-reader, Firefox, WebKit, mobile, Linux, and macOS coverage. Longer term, we would consider user-controlled synchronization only if the local workspace remains authoritative and the product's privacy and review-before-apply principles are preserved.

Built With

• css
• javascript
• next.js
• python
• sqlite