OurCar: What I learned making an app for my family

· devtools · Source ↗

TLDR

  • Builder made OurCar, a Flutter + Pocketbase app to solve car-sharing logistics for his family, covering gas tracking, location, and scheduling.

Key Takeaways

  • Stack: Flutter with Riverpod and Auto Route on frontend, Pocketbase backend with hooks for push notifications; chosen for prior familiarity and proved sufficient.
  • Gas tracking works by combining trip odometer and trip efficiency readings to calculate fuel consumed per trip, entered manually at car return.
  • GPS tracking was deliberately excluded: live location drains battery and exposes private trip destinations to all family members; only parked location is shared.
  • Flutter’s lack of automatic platform-adaptive widgets forced reliance on the flutter_platform_widgets package, resulting in spaghetti layout code across Material and Cupertino.
  • Distribution via App Store and Play Store beta channels was painful upfront, especially Apple notarization; author eventually paired wife’s phone directly to developer account.

Hacker News Comment Review

  • Commenters split on manual data entry: skeptics argue it is too unreliable at scale and that OBD-II integration would be necessary for real-world use; author counters the app targets trusted groups where friction reduction matters more than automation.
  • Flutter cross-platform native feel drew scrutiny; one reply argued Expo with expo-ui now outperforms Flutter for matching native iOS/Android look and feel, especially post-Liquid Glass.
  • Broader thread surfaces a recurring pattern: small-audience family tools are low-stakes enough to absorb LLM-generated code for uninteresting flows while keeping manual effort for the parts worth learning.

Notable Comments

  • @tantalor: “Good example of over-engineering. This could be easily solved with a pencil and notepad.”
  • @fmajid: argues manual entry fails without OBD-II fuel data plus presence tracking for reliability at any real scale.

Original | Discuss on HN