A small website your household opens on a phone: what is coming up, when each child's day starts, and who to call.
This is a prompt for an AI coding assistant. It builds a small private website with a page for each child and a shared home page for what is coming next. The content is encrypted, so the calendar is not readable by anyone who finds the address.
The dashboard has no accounts, no database and no tracking. It runs on free static hosting, so there is no bill for the site itself.
There are two parts. This page builds the dashboard. The second keeps it up to date.
Have a look at one first — a working demonstration with an invented family, no passphrase needed.
It will ask you for names. Your answers go into the conversation, so if you are privacy-sensitive, find out where your AI tool keeps its chat history before you type real names, schools and contacts. You can answer with placeholders at first and correct them later.
Paste it in and it will ask you everything it needs.
Walk me through building a private family dashboard: a small website my household can open on a phone to see what is coming up, when each child's day starts and ends, who to call, and where the links are. I have not done anything like this before, so be my guide. Ask me one thing at a time and wait for the answer. Say what you are about to do before you do it, in plain words. Tell me when something will take a while, and tell me when I need to make a decision rather than deciding for me. START HERE, BEFORE ANYTHING ELSE Tell me honestly whether you can create and edit files on this computer. If you cannot, say so and stop. I need a tool that can, and it is better to find that out now than after an hour. If building this needs anything installed, tell me what and why, and wait for me to say yes. Keep it to the least you can manage. THEN ASK ME ABOUT MY HOUSEHOLD One question at a time: - Who lives here, and what do we call each other. - Each child's name, their school year or age, and the name of their school, nursery or programme. - Which country, region and town each of those is in. Ask even if you think you can guess. Names repeat and I do not want facts from the wrong place. - Anything else with its own calendar: a club, a team, a group. - If any of us goes by a different name from the one on the school's records, which is which. Use the everyday name everywhere on the page, and keep the official one for anything that goes back to the school. THEN ASK ME FOR A PASSPHRASE Explain first, in a few short sentences, why it matters: the finished page sits on the open internet, anyone who knows the address can open it, and the passphrase is the only thing keeping what is inside unreadable to them. Tell me to use several unrelated words, and not to reuse a password from anywhere else. Then put it in a file the build reads. Tell me what that file is called and where it is, add it to the ignore list so it can never be committed, and never print it into anything that gets saved. Do not invent a passphrase for me and do not carry on without one. NOW BUILD IT - Everything goes in a new folder called family-dashboard. - Set it up as a git repository, but do not create a remote or push it anywhere. If I ask for one later, it must be private, and say so out loud rather than accepting the default. - A plain static website. No database, no logins, no accounts, no framework, no analytics, no third-party scripts. - A page or tab for each child, and a shared home page for what is coming next for the whole household. - Phone first, but a proper wider layout for a laptop too. - Put ALL the content in one file I can edit myself, and keep the code separate. PRIVACY — NOT OPTIONAL Hiding the page behind a password box is not enough, because anyone can read the page source. Encrypt the content with the passphrase (AES-GCM, key derived with PBKDF2) so the published page holds nothing readable about us. The unlock screen and the code are necessarily public; everything about my family must be inside the encrypted part. - Make the unlock screen the first and only thing anyone sees: a passphrase box, nothing else. No names, no headings, no hints. - Do NOT add a passphrase hint. Anything shown before unlocking cannot be protected. - Use a high PBKDF2 iteration count. Tell me the number and put it in one named constant so it is easy to raise later. - The salt is not a secret, but it must stay stable and never be regenerated silently. - Keep the site name and ALL metadata neutral: no family name, child's name, school or town in the address, page title, description, manifest, icon, icon alt text or link preview. - Do NOT add "stay unlocked on this device" unless I ask. If I do, tell me exactly what gets stored, where, and for how long, and give me a visible way to undo it. - Make the build fail loudly if the passphrase or salt is missing, and set the site to noindex. - Tell me clearly that the published page is encrypted but the copy on my computer is not, because that is the one I edit. Say what that means for keeping it to myself. - Before I share the link, check EVERY file the build publishes, not just the page, and show me that none of our names, schools, addresses, numbers or schedules appear in any of them. FILLING IT IN — THIS MATTERS MORE THAN THE CODE - Look things up. Find the real staff names, phone numbers, start and finish times, and the school calendar of term dates and holidays. Do not write placeholder text where a real fact is published. - Show me what is verified and what is not, on the page itself. Every fact carries where it came from and when you checked. Anything you do not know goes in a visible "still to find out" list. - Blank beats guessed. - Never assume one child's rules apply to another. Absence procedures, dress codes and schedules are set per school. - Tag every item with the child it belongs to, or as the whole household. If you cannot tell, ask me. Never quietly default to one child, because a shared item then appears with someone's name on it and reads as theirs. - When you filter the page to one child, match on what to KEEP, not on what to leave out. - When two sources disagree, prefer the newer and more specific one, tell me there was a conflict, and say which you used. - If something you told me turns out to be wrong, correct it where I can see, not silently. I may have acted on it. PRACTICAL - Store dates as YYYY-MM-DD and work out the weekday in code. - Work out today's date in MY timezone, not UTC. The obvious one-liner in most languages returns UTC, which rolls the page over to tomorrow during our evening and hides what is left of today. - Warn me that editing the content file changes nothing until it is rebuilt, and give me a simple way to check whether the live site is current. Do not compare the published file against a fresh build: encryption uses a new random value each time, so that always reports out of date. Derive it from the source instead, and key it with a separate random secret kept out of version control, never with the passphrase. - Give me a way to preview a future date in the address bar, like ?date=2027-03-01. - Make phone numbers tap-to-dial, and tell me how to add the site to a phone's home screen. KEEPING IT FED School news arrives as paper in a bag, or as an email. When I show you one — a photo, a screenshot, a PDF, or text I have pasted in — read it and put the details into the dashboard, following the same rules above. If you can reach my email yourself, tell me so, and then I can just say "there's a new one from the school" instead. PUTTING IT ONLINE Show me it working on my own machine first. Then explain, step by step, how I put it on the internet myself by dragging the built folder onto a free static host. Do not publish it for me, and do not publish it later without asking, however small the change. Free plans limit how often I can publish, so gather changes up and publish once rather than after each edit. WHEN WE ARE DONE Write a short file of instructions for whatever AI opens this folder next — CLAUDE.md, AGENTS.md, README-AI.md, whichever mine reads. Assume the next session remembers none of this and may be running with nobody watching. Put "never publish without asking" first, under its own heading, in the strongest words you have. Then: never commit or print the passphrase, never delete or regenerate the salt, never hand-edit the generated output, always rebuild after editing the content file, and never apply one child's school rules to another. Then tell me the dashboard will go out of date unless something keeps feeding it, and that there is a second prompt for that.
When it works, come back for part two.
It will ask which town each school, nursery or programme is in, because names repeat and it should not guess. Everything below says "school" for short, but the same applies to any of them.
How much it finds on its own depends entirely on what your schools publish. Where there is a public website listing staff, phone numbers, start and finish times, and a school calendar with term dates and holidays, it will usually pick those up. Where there is not, or where the details sit behind a parent login, on a social media page, or in a language it reads poorly, it will come back with much less.
Some things are rarely published anywhere. Absence procedures, dress codes and lists of what to buy or bring often arrive only by email or on paper. When one turns up, show it to your assistant: photograph the paper one, or paste in a screenshot or the text of the email. If your tool is connected to your email, you can simply ask it to read the one that arrived. Either way it puts the details in for you.
Expect gaps in the first build. The prompt tells it to put anything it cannot verify into a visible list of open questions instead of filling the space with a guess.
Everyone types the passphrase each time they open the page. You can ask for it to stay unlocked on your own phones instead. The trade is that the phone then holds the key, so anyone who can open that phone can read the dashboard — worth deciding on purpose rather than by default. Either way there is a Lock button on the page.
At some point it will. None of these need you to understand the code.
Most of this is handled by the prompt. There is no hint about the passphrase anywhere on the page, no names in the title or the web address, and nothing identifying in what a visitor sees before they unlock it. Two things are up to you.
The copy on your own computer is not encrypted. That is the one you edit, so it has to stay readable. Keep it to yourself, and do not put that folder online.
The rest of the prompt is about accuracy.
School information keeps arriving after the site is built. Dates change, staff change, and new deadlines appear. Unless something adds them, the dashboard goes out of date.
So there is a second part to this: a weekly task that reads school updates, updates the dashboard, and either adds the dates to your calendar or gives you a list to add yourself. It has its own prompt on a separate page.
There is no database, no login system, no framework and no analytics. Each of those would add an account to manage, a bill, or a dependency that breaks. A static encrypted page has none of that.
Most of the value comes later, as you keep showing it the flyers and emails that would otherwise sit in a bag or an inbox.
Shared as it is, for free, with no warranty of any kind. What you build with this is yours to look after — including the passphrase, which is the only thing standing between your family's details and anyone who finds the address. Check the result yourself before you rely on it, and before you share the link.
Not affiliated with, endorsed by, or connected to Anthropic, OpenAI, Netlify, or any school or district. What those tools can do, and what they cost, changes often; confirm anything that matters to you.
Nothing here is legal, security, or professional advice.