Go back
Go back

Omono

Mobile App

Created bySzymon Dziedzic

Public voting opens soon — nominees are live now.

Omono - Primary Image
Main
Omono - Secondary Image
Gallery
Omono - Additional Image
Extra

Overview

Omono is the command center for a family. Calendar, shopping lists, budget, gifts, notes and the family map in one app, shared in real time. Built and shipped to the App Store in two months by one person with an AI coding agent.

Project Details

Category

Mobile App

Customer

Self initiated product, internal work

Submitted by

Szymon Dziedzic

Timeframe

May to June 2026

Tech Stack

Flutter, Dart, Riverpod, go_router, Supabase (Postgres, row level security, Realtime, Storage, Edge Functions), Firebase Cloud Messaging, RevenueCat, Mapbox, Hive, Figma, GitHub Actions.

Services

Product strategy, UX and UI design, design system, Flutter development, database and backend design, monetisation, store release. All of it.

Demo Link

-

Team

Szymon Dziedzic: product, design, architecture, every technical decision and review of every commit. An AI coding agent: the pair that wrote the app, the SQL and the edge functions from written specs. No agency, no contractors.

Link to case study

-

Description

THE INITIAL PROBLEM. A family runs on shared information that lives nowhere. The dentist appointment sits in one private calendar, the shopping list is on the fridge, the household budget is a spreadsheet nobody opens, and the answer to who is picking up the kids today is somewhere in a message thread. Every family app on the market solves one slice of this: a calendar, or a list, or a location tracker. Asking four people to install five apps and keep all of them current is not a plan, it is the reason the fridge list survives. I wanted one place where the whole of family logistics lives together, where a change made by one person is visible to everyone in the same second, and where the boring safety questions, where is everyone and is everyone alright, are answered without yet another subscription. THE PLAN. Four constraints were fixed before a line of code was written. First, one home and one shared truth: everything belongs to a home, every member sees the same data, and every write is authorised in the database rather than in the interface. Second, real time by default: if somebody ticks the milk off in the shop, the phone in the kitchen updates immediately, without a pull to refresh. Third, security lives in Postgres: row level security on every table, and every privileged action, meaning push notifications, account deletion, receipt scanning and subscription webhooks, behind an edge function, so no secret ever ships inside the app. Fourth, two languages and two themes from day one, because a family app is used at six in the morning and at eleven at night, and the same household often mixes Polish and English. THE TEAM. Szymon Dziedzic, product owner, designer and engineer, responsible for the product definition, the interface, the data model, every technical decision and the review of every commit. An AI coding agent as the pair that wrote the Flutter code, the SQL migrations, the edge functions and the release tooling from written specifications, in a tight review loop. The working agreement lives in the repository: a contract file that tells the agent how this codebase works, and a memory bank that records the schema, the flows and the conventions and is updated as they change. No agency and no contractors, a one person studio working with an AI pair. EXECUTION. The app is Flutter with a feature first structure, Riverpod for state and go_router for navigation. Six modules share one home. The calendar handles recurring events, reminders and assignment to individual members, with a colour per person. Shopping lists sort themselves into categories and update live, so two people in two aisles never buy the same bread. The household budget takes a monthly limit, splits spending by category and by person, and can read a receipt from a photo instead of asking anyone to type it in. Gift wishlists carry reservations that stay hidden from the person the list is for, which is the only way a shared wishlist actually works. Notes and checklists come with ready made templates for packing, for a babysitter and for the school year. The family map shows live location, a location request that takes one tap, and an SOS alert that reaches the whole home at once. The backend is Supabase. Sixteen tables, every one of them under row level security, forty nine policies, and Realtime subscriptions that push every insert, update and delete to the other phones. Seven edge functions handle everything the client is not allowed to do, including notification templates that are built server side and selected by type, so a client cannot craft a push that pretends to be somebody else. Payments run through RevenueCat with a free tier that stays useful and four paid plans. On the front the interface is one design system across thirty four screens, light and dark, seven hundred and twenty two localised strings in Polish and English. The store artwork and the images in this submission were built as vector compositions in Figma from the same components as the app, so the marketing never drifts away from the product. WHAT IT COST AND WHAT BROKE. About two months from an empty repository to a live App Store release. The hard parts were never the features. Row level security fails closed and it fails quietly: a blocked write returns success with zero rows affected, so the interface happily showed a green toast for an edit that never happened. That single pattern produced eight separate defects, in eight different places, and forced a rule that every write checks what actually came back. Realtime deletes never arrived at the other phones until the tables were switched to full replica identity, because Postgres sends only the primary key otherwise and the client had nothing to match on. All day events slid one day backwards for anyone outside UTC until every timestamp was stored in UTC and rendered local. Push notifications were silent on iOS for days because of one missing entitlement, and silent on the server because the send path returned success before it ever authenticated with the push service whenever the recipient had no registered token. Apple rejected the build twice, once for an in app purchase that had not been submitted for review and once for a description that advertised features sitting behind the paywall. Each one was diagnosed and answered within a day. LESSONS LEARNED. Never trust a write that did not tell you what it wrote. A database that fails closed is correct and an interface that assumes success is not, and the gap between those two is where the worst bugs live, because nothing crashes and nobody complains. Audit by tracing the whole path, from the button to the provider to the service to the row, because an audit that stops at the service layer will happily approve a limit the user can never actually set. Timezones and recurrence are where family calendars really break, long before anything interesting happens. And an AI pair multiplies whoever is steering it: output quality tracked specification quality almost exactly, which is why the schema, the flows and the conventions were written down first and kept current to the last commit.

Why Us

One app replaces five, and all of it is shared state. Every table sits behind row level security, every privileged action runs server side. Two months, one person with an AI pair, empty repository to the App Store.
https://apps.apple.com/app/omono/id6757364293

Explore More

Previous Editions

Category

Mobile App

Public voting opens soon — nominees are live now.