OurCar: How a Family App Validated Rapid Development

Mendel Greenberg built OurCar to solve a specific family problem. His approach offers a playbook for rapid validation and development, even without immediate commercial intent.

Mendel Greenberg built OurCar, a mobile application designed to solve a single, recurring family problem: coordinating car usage. The project, detailed on his personal blog, removed the friction of "who has the car?" text messages by allowing family members to check out and check in a shared vehicle. This focused approach, prioritizing a specific internal pain point over broad market appeal, demonstrates a rapid development cycle for immediate user value.

Pinpointing a Specific Family Problem

Greenberg identified a clear, internal communication breakdown within his family. The constant stream of text messages asking "who has the car?" or "when are you bringing it back?" represented a direct, repeatable point of friction. His approach was not to survey a broad market, but to address a known, daily annoyance for a defined user group: his immediate family. This provided instant problem validation without external market research. The problem's specificity meant that the solution's scope could remain narrow, preventing feature creep common in early-stage projects. The explicit goal was to eliminate a specific type of text message.

Rapid Prototyping with Modern Tools

The technical stack for OurCar prioritized developer velocity. Greenberg used Expo and React Native for mobile development, allowing a single codebase to target both iOS and Android. Firebase served as the backend, leveraging its Authentication, Firestore database, and Cloud Functions for serverless logic. This combination significantly reduced setup time and ongoing maintenance overhead, enabling a solo founder to focus on feature implementation rather than infrastructure. The choice of Firebase, specifically, eliminated the need for custom server management or complex database schema design in the initial stages. This allowed Greenberg to move from concept to functional application quickly, a critical factor when building for a small, internal user base.

Iterative Development Driven by Direct Feedback

The family served as the initial and primary user base, providing immediate and unfiltered feedback. Early iterations of OurCar included features like a simple check-out/check-in mechanism and a display of who currently held the car. Feedback from family members led to the addition of features such as displaying when a car was due back and a notification system for car returns. This direct feedback loop allowed for rapid iteration and ensured that new features directly addressed user needs, rather than hypothetical market demands. The initial user base was small, but their engagement was high due to the personal stake in the problem's resolution. This direct access to users bypassed the complexities of formal user testing or market surveys.

Deferring Monetization for Problem-Solving

Greenberg explicitly chose not to monetize OurCar for its initial family release. He stated, "I considered making it a paid app from the start, but that seemed like a lot of friction for my family." This decision allowed him to focus entirely on solving the core problem and optimizing the user experience without the complexities of payment gateways, subscription management, or freemium tiers. While he integrated Stripe for potential future public release, the initial deployment prioritized utility over revenue, demonstrating a strategy of validating core functionality before introducing commercial considerations. This approach decoupled product utility from business model viability in the early stages.

What We'd Change

The OurCar project provides a blueprint for rapid, problem-focused development for a defined user group. Translating this success to a commercial product requires significant adjustments to the initial strategy.

Commercializing Distribution Beyond a Family Circle

"Sending a link to my family" is an effective distribution strategy for a personal project. For a public application, this approach is insufficient. A commercial version of OurCar would require a multi-pronged distribution strategy. This would involve App Store Optimization (ASO) for both Apple App Store and Google Play, potentially investing in targeted paid acquisition campaigns, and engaging with relevant online communities (e.g., family organization forums, local parenting groups) to generate organic interest. The initial "user base" of a few family members provides no data on broader market reach or acquisition costs. A public launch demands a clear go-to-market plan.

Developing a Viable Monetization Model

Greenberg's decision to defer monetization was appropriate for a family app. For a commercial product, a clear revenue model is essential from early stages. While he integrated Stripe, the specific pricing strategy remains undefined. Potential models for a utility app like OurCar could include a one-time purchase, a small monthly or annual subscription for family groups, or a freemium model with advanced features (e.g., multi-car support, detailed usage analytics) behind a paywall. Each model presents different user acquisition and retention challenges that were not addressed in the family-focused launch. The choice of model impacts product design and marketing.

Scaling User Feedback and Feature Prioritization

Direct family feedback is invaluable for a small project. Scaling this feedback mechanism for a wider audience requires more structured approaches. This includes in-app feedback forms, user surveys, A/B testing, and analytics to understand broader user behavior. Features prioritized by a small family group might not align with the needs of diverse user segments. For instance, a public version might need more robust scheduling, multiple vehicle management, or integration with calendar systems, which were not critical for the initial family use case. Prioritization shifts from immediate family needs to broader market demand.

Addressing Technical Debt and Scalability for Public Release

While Firebase offers rapid development, a public application with potentially thousands or millions of users introduces new considerations. Scaling Firebase efficiently requires careful data modeling and query optimization to manage costs and performance. Additionally, a commercial product often necessitates more robust error logging, monitoring, and security audits than a private family application. These are considerations that were not the primary focus during the initial, rapid development phase. The architectural decisions made for a small user base may not hold for a global audience.

Landing

The OurCar project demonstrates the power of solving a specific, immediate problem with efficient tooling. While the path from a family utility to a commercial success is distinct, the core lesson remains: focused problem identification, rapid prototyping with modern stacks, and iterative development driven by direct user feedback establish a robust foundation. Founders can apply this disciplined approach to validate a core problem and solution, even if the subsequent commercialization strategy requires a separate, equally rigorous execution.

Pull quote: “The family served as the initial and primary user base, providing immediate and unfiltered feedback.”