Last updated 10 September 2026. This covers the FamPlan app and famplan services operated by Spydaz Holdings LLC.
Not to advertisers, not to data brokers, not to analytics companies, not to anybody. We do not rent it, trade it, or hand it over in exchange for anything.
If that ever changes, we will tell you before it does, and you will be able to delete your account and your family’s data first.
FamPlan holds your family's calendar: events, who is going, who is driving, and any chores or balances you record. We store that on our servers so everyone in your family sees the same plan. We do not sell it, we do not advertise against it, and we do not share it with anyone except the services listed below that are needed to run the app.
The app talks to our own server, and to the notification service for whichever phone you use — Apple's on iPhone and iPad, Google's on Android. If someone connects a school Google account so their homework shows up, it talks to Google Classroom as well, and only then; that has its own section below. There are no analytics SDKs, no trackers, and no advertising networks in it.
Some things the app uses never reach us at all:
If a chore asks for a photo as proof, that photo is uploaded to our server so the parent reviewing it can see it. It is stored encrypted at rest, is readable only by the parent it was sent to, and is never used for anything else.
Photos are deleted the moment the chore is answered. Approve it or decline it and the photo is gone from the live database immediately — the parent has seen what they asked for and there is no reason to keep it. A photo nobody ever got round to answering is deleted automatically after 15 days. We keep no archive and no thumbnail.
A copy will still be in our backups for a while. Backups are taken on a schedule and cannot be edited afterwards, so a photo that existed when one was taken is inside it until that backup expires — the same as every other record, and for the same reason, explained under Deleting your family. It is encrypted, never queried, and would only ever come back in a wholesale restore. This is the real reason to think about what is in the frame: not the fifteen days in the app, but the time it takes a backup to age out.
Please be careful what is in the frame. A photo of a tidied bedroom or a mown lawn is the point. Think twice about photographing anything showing a child’s face, a document, a screen, a house number, or anything else you would not want sitting in a backup after the chore is long forgotten. Ask for the corner of the room, not the room and the child.
Event photos are different from proof photos. If you attach a picture to an event — the poster, flyer or permission slip it was read from — that picture is stored on our server and is visible to everyone in your family, because the whole point is that the family can see the original. It is kept only until the event has passed, then deleted automatically, and it is subject to the same backup ageing described under Deleting your family. Attach only what you are comfortable sharing with your family, and nothing you would not want in a backup.
There are two different things here and it is worth being blunt about both, because they get muddled constantly and they are not the same.
We look at how FamPlan is used in the aggregate, and we do not ask permission for that. How many events a typical family creates in a week. Whether people who use chores keep using them. How often a lift goes unclaimed until the day. Which screens get opened and which never do. How often the app reads a sentence and gets it wrong — not what the sentence was.
A worked example, because it is exactly the kind of thing we mean: if families are creating hundreds of events and five chores, that tells us chores are not working and where to spend the next month. We cannot build this well while being blind to how it is actually used, and no version of this involves reading your calendar.
These are counts, timings and patterns — numbers about behaviour, not the content of it. They are not tied back to a person when we look at them, they are never sold or shared, and they never leave our own systems.
This will grow. As we build features like suggesting a time everybody is free, we will need to measure things we are not measuring today. We are telling you that plainly rather than writing a policy that pretends otherwise and quietly widening it later. What will not change is the line: counts and patterns without asking, your family’s actual content only if you say yes.
FamPlan can turn a sentence into an event, and sometimes it gets it badly wrong. The most useful thing for fixing that is the sentence that went in and the correction that came out of it — the actual words, which are about your family.
You can choose to share those with us. If you do, and only if you do, we keep:
Nothing else. We do not keep edits you make to that event afterwards — a change three weeks later is a change of plan, not a correction, and it would teach us nothing. We do not keep events you never asked the app to interpret.
These sentences are about your family, so treat the switch accordingly: turn it on if you would not mind us reading “drop Sam at football Saturday”, and leave it off if you would.
This switch is not the cloud reading. They are two different things. The teaching switch above keeps an adult’s own words to make the reader better; cloud reads and cloud recipes are a separate, per-use choice made by whoever taps them, when the plan allows it — nothing from a cloud read or recipe is kept for teaching, and what they send is listed under Who else sees it below. Cloud AI is a permission: each person has it unless a parent switches it off on their member page, and the family’s owner can switch it off for the whole family — after which nobody but the owner can turn it back on. A child starts with it off until a parent grants it. Nobody can enrol a child in the teaching switch above, whatever their cloud AI permission is.
Separately from that setting, most screens have a Report a problem button. Sending a report is a decision you make once, about one thing that went wrong — there is no setting behind it and nothing is collected unless you press it.
Before it sends, the screen shows you exactly what goes with it, written out rather than summarised. Where a screen can attach something useful — the sentence you gave the app and what it made of it, say — you can read it and switch it off, and only your description will be sent. Always attached: which screen you were on, the app version, and your device model, so somebody can reproduce it without having to write back and ask.
A report is filed as a ticket in our helpdesk (Zammad), and may be processed with AI to suggest a likely cause before a person looks at it. What the AI sees is what is attached to the ticket — the screen, the words involved, the kind of report, your app version, OS and device, and when it happened — and never your name, account, or email address. Pressing Send is your agreement to that.
We use reports to fix bugs and to improve how the app reads what people write. Anyone can send one, including a child — asking for help is not the same as being collected from, and a child who cannot report a problem is a child whose problems never get fixed. Reports are kept until the issue is dealt with. A parent in the family can read a child’s report and its answer, and where a child has no email address of their own, our reply goes to a parent instead. A parent can also switch off a child’s ability to send reports or ask the assistant for AI help; when that is off, the child asks their parent instead.
FamPlan is designed for households, and that means children's information is in it. A child's place in the family is created only by a parent — enrolling a phone with an invite code and PIN, or giving the child a web login with the family handle, their name and a PIN — and only that adult can do it. Doing either is the parent consenting for the child. We collect the same limited information for a child as for anyone else: a display name, what they are going to, who is taking them, and any chores or balances recorded for them.
We do not knowingly let children create accounts on their own, we do not ask children for information beyond what the family calendar needs, and we do not use children's information for advertising or profiling.
A parent withdraws consent by removing the child from the family — that takes them off the roster and signs every one of their phones and web logins out at once. A parent can also remove just a device or just a web login on its own, leaving the child’s place in the family intact; only a parent can do either.
The only hard delete is Delete my family. Removing a member, or revoking a child’s consent this way, is a soft removal: what was recorded is still borne by the family — the events, chores and balances it produced don’t disappear — it is simply no longer attached to that person. It goes entirely only when the family itself is deleted.
A child can also connect a school Google account so that their homework appears in FamPlan. What that reads, and what it cannot, is set out under Homework and school accounts below. It is optional, read-only, and can be switched off by the parent, by the child, or by the school.
If you believe a child's information is in FamPlan without a parent's involvement, email support@spydaz.com and we will delete it.
FamPlan can show a student their own homework next to the rest of the family's week. There are two ways it gets there, and the difference matters.
By hand, or from a picture. Anyone can type homework in. You can also photograph a class page and let the app read it, which uses the same photo reading described above and needs no access to a school account at all.
By connecting Google Classroom. This is optional, off until someone turns it on, and done for one student at a time. While it is on, our server reads the following a few times a day, and only reads:
That is the whole list, and it is deliberately shorter than it was. We do not ask Google who the student is: no email address, no account name, nothing that identifies them beyond the connection itself. A school address is usually a child's name, and we do not need it, because the connection is made from that child's place in your family and we already know who they are. We also do not ask for their submission status or their grades. None of that is needed to put an assignment on a list, and a grade is not ours to hold. If a school chooses to allow submission status anyway, it can be shown on screen and is never written down. These are not settings; the app cannot ask for them.
It asks Google for no permission to write anything at all. It cannot post, comment, submit, edit or delete work, it cannot change a grade, and it cannot see another student's work, a class roster, or a class the student is not in.
What comes back is stored with that family's homework and is visible to that family only. It is never sold, never used for advertising, and never used to train any AI system. It is not passed to any other company either — not to the AI that reads photos, not to the recipe service, and not into email. The permission that lets us read it is encrypted before it is stored, with the key kept outside the database.
An assignment that disappears from Classroom is archived here on the next read. The connection expires by itself after 90 days and has to be renewed deliberately. It can be disconnected at any time in the app, by the student at myaccount.google.com, or by the school. Many schools only allow apps they have reviewed, so connecting may not be possible on a school account at all — that is the school's decision, and the by-hand and photo routes work either way.
Only the companies that have to handle something for the app to work at all, and only the specific thing each of them needs. None of them is given your data to use for their own purposes, and none of them is paid in data.
That is the entire list. If it ever needs to grow, this page changes first and says so.
One more path, only if you open it: a connected assistant. FamPlan lets you connect an outside AI assistant (such as Claude) so it can add events for you. It is optional and off until you turn it on. When you use one, the thing you hand the assistant — a photo of a flyer, a forwarded message, some text — goes to that assistant, under its own privacy policy and terms, not ours; what reaches FamPlan is only the event it creates. We never send your data to an assistant — you do, when you choose to, and connecting one is a decision you make and can undo. Connecting creates a token, stored only as its hash, that lets the assistant act as you within your permissions; you can revoke it at any time from Settings. Connecting one is separate from the AI features FamPlan runs itself — reading a photo into an event, or writing a recipe when you ask — which are listed above and are only ever sent the one image, sentence, or search, never your family's calendar. If you never connect an assistant, your family's calendar is never handed to an outside assistant to act as you.
The one thing outside our control: if we were legally compelled to disclose something, we would have to. We would tell you unless we were forbidden from doing so, and we would give no more than was actually demanded.
Your data is encrypted in transit and encrypted at rest on our servers. Access to the database is restricted, and the app is built so that one family cannot read another's.
FamPlan is not end-to-end encrypted. We hold the keys to the storage, which means we are technically capable of reading what you put in. We do not, and we have no business reason to — but you should know it is true rather than assume otherwise.
No service on the internet is immune from being broken into, and we will not pretend otherwise. Please use judgement about what you type into any cloud service, including this one: a calendar entry is not the place for medical details, financial account numbers, or anything you would be harmed by seeing published. If we discover a breach affecting your information, we will tell you and the authorities as the law requires.
If you are on a pre-release build — a TestFlight build or any version we have marked as a beta — a few things are different, and you should know them before you put real family details in.
A beta build is unfinished, and testing it means we may look more closely at how it behaves. We may collect more diagnostic detail than the released app does — error reports, logs and usage patterns — to find and fix problems, and Apple collects its own crash and usage data for TestFlight builds under Apple’s terms. We use what we collect only to improve FamPlan.
Treat beta data as temporary. A beta build can be unstable, and the data you enter into it may be reset, wiped or lost between builds, or may not carry over to the released app. Because of that, please don’t put anything into a beta build that you can’t afford to lose or wouldn’t want exposed, and keep your own copy of anything important. Participation is voluntary and at your own risk; the Beta testing section of the Terms of Use sets out the rest, and it governs pre-release builds.
FamPlan is a record of what a family agreed, and a record you can quietly rewrite is not much of a record. So cancelling an event, declining a request, or removing something from the calendar does not delete it from the database. It stops appearing in your day, and it is still there — you can see cancelled items yourself by switching on “Include canceled” in the app.
That is deliberate. Who agreed to drive and then pulled out, and when, is the kind of thing families disagree about later, and an app that silently forgot it would be taking a side. These records are kept for as long as the family exists.
Proof photos are the exception and really are deleted, as described above — immediately when a chore is answered, and after 15 days otherwise.
The person who created the family can delete it from inside the app (menu → Family → Delete my family). Every record belonging to it is purged from the live database: events, assignments, balances, ledger entries, photos, lists, recipes, devices, and the member records themselves. Accounts that belonged only to that family — the person who deleted it included — are removed with it; someone who is also in another family keeps theirs. That is a real deletion, not a flag.
It cannot be instantaneous and complete, and we will not pretend otherwise. The database is backed up on a schedule to Backblaze B2, through the same infrastructure that runs our OctoVault backup product. Those backups are immutable: once written they cannot be altered or partially rewritten, by us or by anybody holding our credentials.
That is exactly what you want from a backup — it is why ransomware cannot quietly corrupt it and why we cannot be pressured into editing history. It is also why we cannot reach into one and surgically remove a single family. What happens instead is that each backup expires on our retention schedule, and your data is gone from our systems entirely once every backup taken before the deletion has aged out. Until then those copies exist, are encrypted, are never queried or used for anything, and would only ever be restored whole in a disaster.
Any company promising your data is gone the instant you press delete either keeps no backups or is being loose with you.
Nothing is deleted because a payment stopped. Your family’s calendar stays in the live database and stays readable for one year, so a family that comes back finds their plan where they left it, and a family that stops paying mid-year does not lose their history over it.
After a year without an active subscription, the family is purged from the live database by exactly the same process as a deleted family, and ages out of backups the same way. You can delete it yourself sooner at any point, and you can ask us for a copy of it before it goes.
When you turn on verification codes we give you ten recovery codes and show them once. Any one of them signs you in. That is the fast way back, and the reason to keep them somewhere other than the phone.
If the phone and the codes are both gone, email support@spydaz.com from the address on your account and ask us to turn verification codes off. The app has a link that writes that email for you. Sending it from the account address is how we know it is you; a request from any other address gets nowhere.
It takes a few days, deliberately. We email the account to say a reset was asked for, and wait before doing anything, so that if it was not you there is time to say so. Verification codes exist to protect an account whose password somebody else already has — and email is usually how a password gets reset, so a second factor that can be dropped by one email the same afternoon is not really a second factor. The wait is the part that makes it one.
When it goes through, codes come off and every signed-in device is signed out, so you sign in again with your password. Right now a person handles these; the checks do not change when that becomes automatic.
Email us from your account’s address and we will send a readable file within 30 days. It is written for a person to read rather than exported from the database, and it contains:
Dates and times are written out properly. Inside the database they are held in a machine format that would mean nothing to you, and sending that would answer a request in form while being useless in fact.
It is not a database export. Our schema — the tables, the columns, the internal identifiers tying them together — is our own, and none of it describes you: it describes how the software was built. What describes you is the list above, and that is what you get.
It also will not include proof photos, which are deleted as soon as a chore is answered and so are usually gone before anybody asks, nor the operational logs we keep to run and secure the service.
If you think something about you is missing from it, say so and we will look. The section headed What we store above is the full account of what exists, and nothing is being held back from it.
Spydaz Holdings LLC
support@spydaz.com
(860) 292-0859
If we change this policy in a way that matters, we will say so in the app before it takes effect, and the version you agreed to continues to govern what you shared under it. Every version is dated, and we will keep the previous ones available so you can see what you agreed to and what changed.