Before building a product, build the rules that decide if it’s any good

EduNavigator is a venture I’m building with a partner, Oria: a trust layer between Israeli parents and the flood of digital content for kids ages 4 to 14, a space currently drowning in apps, courses, and series with no real way to know what’s actually worth the time and money. The original plan was 90 days of feasibility proof with zero development, Notion documents and Google Sheets only.

Midway through, we made a deliberate call to change direction: build a real interactive MVP to test the concept with actual parents before investing in the next asset-building phase, not abandoning the discipline of the proof phase, changing the tool. Alongside the product, I built a full quality standard: a pass/fail gate on safety and age-appropriateness, followed by five weighted criteria (pedagogical fit, professionalism, reliability, clarity of the offer, commercial transparency). I deliberately didn’t set a final pass threshold, it will be defined only once real scoring data exists on the first 50 items, not a guess. When it became clear the product needed content that’s actually managed (approve, decline, hide) without touching code, I honestly re-examined the original "no backend" assumption and built a Supabase backend with row-level security: the public sees only approved, visible items, the admin sees and edits everything. All the data that used to live hardcoded in the app moved there as pending, hidden items by default, until someone actually reviews them. In parallel, a real parent questionnaire already went out to real parent groups on WhatsApp and Facebook, and responses are starting to come in.