Product architecture
Hearth
A cross-platform home-maintenance application designed to help homeowners understand, maintain, and preserve the long-term history of their home.
- React Native
- Expo SDK 57
- Expo Router
- Supabase
- PostgreSQL
- Cloudflare R2
The ownership container for members, components, documents, history, and access rules.
Ownership · Access isolation · Deletion · Audit history
01 / Context
What it solves
Home ownership creates a long trail of disconnected information: appliances, maintenance schedules, warranties, contractor details, costs, risks, and documents. Important context is often scattered across email, paper records, calendars, and memory.
Hearth is intended to make that information useful as a system rather than another collection of notes. Its focus is structured ownership and maintenance—not generic DIY content or an open-ended AI chat experience.
02 / Product shape
A durable ownership loop
The product is organized around a repeating sequence that becomes more valuable as the home history grows.
- 01Set up the home
- 02Understand its assets and components
- 03See what needs attention
- 04Record completed work
- 05Preserve documents, costs, warranties, and contractors
- 06Build a durable history of the home
03 / Requirements
What the system needs to handle
- Work across iOS and Android without maintaining two independent products.
- Let homeowners begin with limited information and enrich their records over time.
- Keep home data isolated according to membership and access rules.
- Preserve maintenance history while making deletion behavior understandable.
- Support documents and flexible home attributes without weakening the core relational model.
- Leave room for reminders, seasonal intelligence, risk scoring, and carefully scoped AI-assisted insights.
04 / Architecture
Engineering decisions
Progressive data entry instead of exhaustive onboarding
A homeowner should be able to establish a useful home record without cataloguing every appliance, document, and maintenance detail on day one. The model supports gradual enrichment so the product can create value before the dataset is complete.
Stable domain concepts before feature-specific tables
The schema centers on Home, Component, WorkRecord, Contractor, Warranty, and Document. These concepts describe the homeowner's world and remain useful as screens and workflows evolve. Relational columns hold durable structure, while JSONB is reserved for attributes that genuinely need flexibility.
Derived history instead of duplicated totals
Work records form the source of truth for completed maintenance and cost history. Spending summaries and timelines can be derived from those records, avoiding redundant values that could drift out of sync.
Platform capabilities before additional dependencies
The application uses Expo and platform-native capabilities first. A third-party library or separate service is introduced only when it closes a concrete capability gap or creates a necessary trust boundary.
05 / Trust
Reliability and privacy
Home records are personal and long-lived. Their access and lifecycle need to be understandable, not hidden behind product language.
Home-owned access
Data belongs to a home and is exposed according to explicit membership rules. Supabase authentication and PostgreSQL row-level security provide the foundation for enforcing that isolation close to the data.
Deletion with visible consequences
The intended deletion flow uses soft deletion, a 30-day grace period, and a clear purge date. Session access is revoked immediately even while recoverable data remains within the grace period.
Documents as sensitive data
Warranties, invoices, contractor information, and home details can reveal more than ordinary app content. Cloudflare R2 stores document objects separately, while database records retain ownership and metadata needed to authorize access.
Plain-language failures
Errors should tell homeowners what happened and what they can do next. This matters especially for uploads, account access, and destructive actions where vague failures can damage trust.
06 / Reasoning
Trade-offs
- A single managed backend reduces operational surface area and early cost, but makes careful schema design and provider boundaries more important.
- JSONB accommodates varied home-component attributes, but using it everywhere would weaken validation, querying, and relationships. It remains a deliberate exception within a relational model.
- Derived totals reduce consistency problems, though expensive summaries may eventually need measured caching or precomputation as real usage grows.
- A cross-platform application increases product consistency and development leverage, while some device-specific behavior may still require platform-aware implementation.
07 / Status
Current status
Hearth is actively being rebuilt. The current phase is correcting earlier architectural issues and establishing a cleaner foundation before expanding the feature set.
The immediate priority is durable domain modeling, predictable access boundaries, and a product loop that remains useful as a homeowner's history grows. Features such as seasonal intelligence, scoring, reminders, and AI assistance should build on that foundation rather than define it prematurely.
08 / Reflection
What the rebuild is reinforcing
- Model real ownership scenarios before designing screens around them.
- A simpler system is easier to reason about, secure, and change while the product is still learning.
- Deletion, access, and document handling are product behavior—not backend implementation details.
- AI is most useful when it strengthens structured workflows instead of replacing them with an unbounded chat interface.