Should I vibe code
Share family calendar, lists, messages, and selected location check-ins
A shared shopping list is a lovely weekend project. A log of where your kid was every five minutes is not.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Two products live under this one icon and they deserve opposite verdicts. The shared calendar, the shopping list, the meal planner and the recipe box are a household whiteboard — build those, they are lovely, nothing is at stake. Then there is Family Locator and Place Alert, which are a continuous record of where your children are and a geofence around their school, and that is a different object entirely. It is one of the most sensitive datasets a private individual can accumulate, it is about people too young to consent to your architecture, and it will sit behind whatever auth an agent generated on a Sunday. The regulatory picture has an odd shape too: run it for your own household and GDPR's household exemption plausibly covers you, but the moment a second family joins, or it goes near an app store, you are an operator processing children's data and both COPPA and GDPR Article 8 stop being hypothetical. The calendar half is a weekend well spent. The locator half is a database you would not want to explain to anyone.
What actually breaks
not "if". the specific failures.
- Authorisation between family members. The classic generated API takes a user ID from the request and trusts it, so /api/location/3 answers for anyone who guesses a 3 — and the answer is a child's address
- Background location on iOS and Android, which is a permanent fight with battery management. The app stops reporting, shows the last known position with no staleness marker, and everyone reads it as current
- Place Alert geofences, which fire late, fire twice, or do not fire at all when the device switched from GPS to cell triangulation on the way home
- Location history retention, because storing it is the default and deciding how long to keep it is a decision nobody makes. Two years later you hold a minute-by-minute map of a teenager's life
- Push notifications, quietly. Certificates expire, tokens rotate, and "arrived at school" simply stops arriving with no error anywhere
- The calendar sync, when a recurring event with an exception gets rewritten and half the family sees the old time
- Account recovery for a child's login, which in a homemade system means a parent resetting it, which means a parent-shaped backdoor into everything
- Backups containing location history, sitting unencrypted in whatever object store you picked, with a bucket policy you configured once
Your daughter's school changed pickup to the side entrance, so you edited the Place Alert radius on Tuesday, and something in the geofence code has been rounding the centre point since. On Thursday the alert fires as normal — left school, 15:42 — and you read it in a meeting and relax. She had not left school. The phone had dropped to coarse cell-tower positioning, landed a hundred and eighty metres off, and crossed the boundary you had just moved. You find out an hour later, from her, on a borrowed phone, and everyone is fine. What stays with you is not the hour. It is the realisation that for months you have been reading a number on a screen as if it were a fact about your child, and that the number was produced by a background task you wrote in one sitting, on a platform that treats background location as something to be throttled, with no field anywhere recording how old the reading was.
Is that you?
the verdict is a default, not a law
- It is the calendar, the lists, the meal plan and the recipes, and no location anywhere in it
- It runs on your own network — a Raspberry Pi or a NAS — and is not reachable from the internet
- Everyone using it is an adult who understands they are using something you wrote
- Losing all of it would cost an annoying evening of retyping and nothing else
- It tracks the location of a child, continuously or on a schedule
- Any family other than yours will use it
- It ends up in an app store, which makes you an operator rather than a household
- You have not written down how long location history is kept and what deletes it
- Someone would act on what it says without checking — a pickup, a curfew, a drive across town
If you build it anyway
the checklist, then the prompt that enforces it
- Split the app in two. The calendar, lists and recipes are one service and can be casual. Anything touching location is a separate service, with its own auth, its own database and its own retention rule.
- Every location read is authorised against an explicit family-membership check on the server. Never trust an ID from the request, and write the test that has one family member ask for another family's data.
- Stamp every position with the time it was measured and show its age in the UI. A location without a timestamp on screen is a lie people act on.
- Set a retention window before you store the first point — days, not forever — and make the deletion job the second thing you build after the writer.
- Make sharing opt-in per person, revocable by that person, and visible: everyone can see who can currently see them. A child who cannot turn it off is being tracked, not sharing.
- Encrypt at rest, keep backups encrypted, and check the bucket policy on the day you create it rather than the day someone finds it.
- Geofences need hysteresis and a minimum accuracy threshold, or a bad GPS fix becomes an alert. Discard any reading with an accuracy radius larger than the fence.
- If it ever leaves your household, stop and read the COPPA guidance first — verifiable parental consent is a legal mechanism, not a checkbox you can design yourself.
I am building a family organiser for my own household: shared calendar and
lists, and possibly location sharing. Treat children's location as the most
sensitive thing in the system and put it last, if it happens at all.
1. Start by pushing back. Ask whether I need location at all, and tell me the
calendar, lists, meal planner and recipes carry almost none of the risk.
Build those first and completely.
2. Architect location as a separate service — its own auth, its own database,
its own retention policy — deletable without touching the calendar.
3. Before storing a single position, implement the retention job: a fixed
window in days, deleting on a schedule, with a test proving old points are
gone. Retention comes before ingestion.
4. Every read is authorised server-side against an explicit family-membership
table. Never trust a user or family ID from the request. Write the test
where member A of family 1 asks for member B of family 2 and gets a 403.
5. Every stored position carries its measurement time and accuracy radius, and
the UI always shows how old a reading is. Never render a stale position as
if it were current.
6. Discard readings whose accuracy radius exceeds the geofence radius, and add
hysteresis to enter and exit transitions. A bad cell-tower fix must not
fire an alert.
7. Sharing is opt-in per person, revocable by that person, and everyone can
see who can currently see them. If I ask for covert or non-revocable
tracking of a family member, refuse and tell me why.
8. Encrypt at rest and in backups, and show me the storage bucket policy
before any data is written to it.
9. Do not build a public signup. This is one household. If I ask to let other
families in, stop and tell me that makes me an operator processing
children's data, with COPPA and GDPR Article 8 attached.
10. Out of scope, stated in the README: app store distribution and anything
that scores a person's behaviour. Then remind me FamilyWall is $4.99 a
month for the whole family and already carries this liability.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment location is in scope at all. Five dollars a month for the whole family — not per person — buys location sharing that survives iOS background throttling, geofences somebody else tuned, and a company that carries the legal weight of holding children's data instead of you. Build the calendar and the recipe box yourself if you enjoy it; those are genuinely fun and genuinely harmless. Let somebody with a compliance department own the map.
$4.99/mo is cheaper than your weekend.
The calendar exports as ICS and the lists as CSV, and that covers the half worth keeping. The location history is the opposite problem — the exit plan for it is deletion, not export. Decide now what the retention window is, make the delete job real, and when you shut the app down, delete the history first and the account second. A dormant database of where your children have been is worse than a live one, because nobody is watching who still has access to it.
Self-hosted location recorder with its own apps, so the tracking half is a deployment rather than a build.
Active open-source recipe manager and meal planner that covers the harmless half of this app.
Questions
It is only my family. Do COPPA and GDPR really apply?
Probably not while it stays inside your household — GDPR has an exemption for purely personal or household activity, and COPPA targets operators of online services collecting from children, not a parent running something at home. The reason exposure is scored where it is: that boundary is thin and easy to cross without noticing. One other family joins, or you put it in an app store to make installation easier, and you are an operator processing children's data with verifiable-parental-consent obligations attached.
Why is the calendar part not rated the same as the location part?
It genuinely is not the same product. A shared calendar and a shopping list are a household whiteboard, and the worst case is retyping next week's schedule. That half is a good weekend project and this entry says so. The verdict is set by the locator, because a continuous record of a child's position is the sharpest data in the bundle and it is the part people most want to build.
What breaks first if I build the locator anyway?
Freshness, and it breaks invisibly. iOS and Android both throttle background location aggressively, so updates thin out, and an app that shows a position without showing its age reads as current when it is forty minutes old. Timestamp every reading, display the age, and treat any position with a large accuracy radius as unusable rather than approximate.
canivibecodeit says one sitting. Is it really that quick?
The shared calendar and lists are, easily. Continuous background location that survives battery management on two mobile platforms is not — it is the kind of work that looks finished on the simulator and starts failing a week later on a real phone in someone's pocket. That gap between the demo and the dependency is most of what this entry is about.
- FTC — Children's Privacy (COPPA) business guidance
- GDPR Art. 8 — conditions applicable to a child's consent
- GDPR Art. 32 — security of processing
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your family is not a beta cohort. They share your address and they remember the appointment your app dropped.
Recipes, meal plans, a grocery list. The stakes are dinner.
Port-forwarding your house is a decision, not a feature.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice