No surprises

Where the product actually is

CubbyLoop is in active development. The daily loop is built, runs end to end and is covered by tests. The server behind it is deployed, and the app's data layer has now been driven against it for a whole fictional day. No screen has been rendered against it, sign-up is not open, and nothing on this page is a date.

The gap

What is not connected, and what cannot happen

This is the part a center should read first, because it is the part that decides whether CubbyLoop is usable today. It is not.

Not yet

No screen has been rendered against the real server

The build in every screenshot on this site is the offline demo, which keeps its records in memory on the device. A second build talks to the deployed project, and its data layer has been driven through the whole day there — but the screens themselves have only ever run against the demo and a local emulator. “The repository works against production” and “the product works against production” are two different claims, and only the first one is proven.

Not yet

There is no sign-up

No screen creates an account, there is no password reset and no email verification, and no invitation has ever been sent. The only way into the deployed product is a developer running a build with a flag. Sign-up opens when the product is ready for a real center, not before.

Not yet

Nothing can be delivered to anyone

No email, no text message, no push notification. An invitation cannot reach a parent, so a family cannot be linked outside the demo.

Not yet

No operational safety net

No monitoring, no alerting, no crash reporting, and no restore that has actually been practised. A product holding a center's attendance record does not open without those.

Deployed

What is running on the production project

Deployed and checked, rather than written and hoped for. None of it is reachable by a center yet, because nothing in the app offers an account — which is why it sits under the gap rather than above it.

Deployed

58 server functions, live

The callables that create a center, invite staff and guardians, record attendance and daily events, delete an account or a whole center, and handle data-rights requests are deployed and active on the production project. An unauthenticated request to any of them is refused.

Deployed

Deletion, deployed and exercised there

Deleting your own account, deleting a whole center with a seven-day window to change your mind, and the scheduled purge that carries both out are live, and were driven against the deployed project rather than a local stand-in. The purge runs every two minutes and has run clean since. Deploying it found two faults nothing local could: an index that could not serve the purge's own query, and a cached record that kept the deletion notice off the screen.

Deployed

Access rules, deployed as server rules

Classroom scope, family scope, the role capability matrix and append-only attendance now run as deployed Firestore rules, with 53 composite indexes deployed and built beside the queries that need them.

Deployed

An adversarial test suite that can fail

The rules are covered by a suite that deliberately attempts cross-family, cross-classroom and cross-center access, with a check proving the suite is not passing vacuously.

Deployed

Sign-in infrastructure, switched on

Email and password authentication is enabled on the production project, and the client has signed up and signed in against it — a verification harness has created fictional centers there and walked the day through them. No real person has an account, because nothing in the app offers one.

Deployed

The app's data layer, driven against it

A harness ran the whole daily loop against the deployed project through the app's own repository code: sign up, create a center, a room, a family and a child, check in, record two updates, read both boards back, check out, replay a request to prove it does not double-record. 61 checks, none failed. It found four bugs a local emulator structurally could not.

Deployed

File storage, deliberately shut

The storage bucket exists with deny-all rules and no upload path. Photos are a later phase, and they are not getting a bucket open in advance of the consent design.

Deployed

Subscription billing, in test mode only

The plan, trial and dunning logic is written and tested, and the payment webhook is deployed and verifies signatures. Nothing has ever been charged, on any account, in any mode.

Runs today

Built, running and tested in the app

This is the full list, and it is the same list the what it does page is drawn from. You can walk all of it in the guided demo.

Arrival and pickup. Check a child in, and check them out against the adult who collected them. At most one open session per child per day, and a retry never opens a second one.
Corrections that keep the original. An arrival recorded against the wrong twin is corrected with a reason. The correction references the original rather than overwriting it, so the day still reads honestly a month later.
The day, in a few taps. Meals, bottles, naps, diapers, toileting, activities and a short note. Each type has its own closed set of fields, so a meal cannot be saved as a shapeless blob of text.
A feed scoped to one family. A parent sees their own linked children and that day's updates. They cannot reach a classmate, another family, a roster or a staff directory — and that is proven by tests, not by hiding a button.
Classrooms and staff scope. A teacher sees the rooms they are assigned to and nothing else. Remove the assignment and the access goes with it. A suspended membership authorizes nothing at all.
Protected guardian links. A family link is created only by accepting a one-time invitation, never by editing a field. Invitations expire, can be revoked, and a replayed acceptance is safe.
Honest offline state. An update recorded with no signal says "saved on this device — not yet received by the center", and the family does not see it until it arrives. Nothing pending is ever called saved.
The center's own day. Service dates and day boundaries are computed in the center's time zone, including daylight saving, so an evening pickup lands on the right day.
A director's board that counts. In the building, open sessions, updates still waiting to sync, and what needs a person — counted from the records, with the time it was counted printed next to it.
An audit trail. Guardian linking, scope changes, attendance corrections and checkouts are recorded with the reason and the role — and without a child's name in the stored detail.
Families, children, enrollment. Families, enrollment, classroom transitions and authorized pickups. The roster a phone reads never carries a date of birth; that lives in a separate restricted record.
Every awkward state, designed. Loading, first-use empty, filter-empty, offline, pending, denied, error-with-retry and suspended. Every data-bearing screen is tested in all of them.

Not built

What we are not pretending to have

These are listed so you can judge the direction — not so you can plan around them. None has a committed date, and nothing on this list should be read as shipping. Where something half-exists, the note says exactly which half.

Not built

Sign-up and real accounts

Sign-in is live on the production project and the functions that create a center are deployed — a test harness has signed up, created a fictional center and walked the whole day against them. What does not exist is a way in: no sign-up screen, no password reset, no email verification. You cannot start a center today.

Not built

Photos and video

No camera, no upload, no storage pipeline. The storage bucket exists with deny-all rules and nothing else. When it is built it will be behind explicit per-child guardian consent, which is a design problem before it is a feature.

Not built

Messaging and announcements

Family threads and center notices exist as screens in the demo, and the server functions behind them are deployed and tested. Nothing connects the two yet, and there is no way to deliver a message to anyone who is not already looking at the app — so we do not count it.

Not built

Push, email and SMS

There is no notification delivery of any kind. The product cannot send anything to anybody — not a message, not an invitation, not a password reset.

Not built

Incident reports

Not started. It needs immutable submitted versions, director review and guardian acknowledgement before it is worth having, and a half-version of it would be worse than none.

Not built

Tuition, invoices and payments

The invoice model and the tuition screens exist with fictional figures. No payment provider is connected to them, no charge can be created, and CubbyLoop would not hold a family's money in any case.

Not built

Enrollment inquiries and forms

There is an enrollment pipeline and a staff rota in the demo, with no backend behind either. There is no public inquiry form, no waitlist a family can join, and no document acknowledgements.

Not built

Imports and exports that leave the device

CSV import with preview, duplicate detection and undo is written and tested, and so is report export. Neither is connected to a server yet. A request to export a center's records, or to delete a child's, is recorded and routed to the center for review and is not executed by software. Deleting your own account is a separate thing: it is deployed, it runs immediately, and it has its own page.

Not built

More than one location

One center, one location. Every record already carries a location, so this is groundwork rather than a rewrite — but the multi-center plan on the pricing page is a published price, not a working feature.

Not built

Operational readiness

No monitoring, no alerting, no crash reporting, and no tested backup and restore. A product holding a center's attendance record does not launch without a restore it has actually practised.

Precisely

What you are looking at in the screenshots

Every screen on this site is a real capture of the app running its offline fictional demo. It carries its own invented center and runs the whole daily loop on the device.

The sign-in screen picks a fictional identity. There is no password anywhere in the demo, because there is nothing in it to authenticate against.
It cannot reach the deployed server. The demo build is prevented at build time from pointing at anything but itself, and a release build cannot be pointed at a demo backend either.
It cannot contact anybody. No email, no text message, no push. Every fictional staff address is an .example address, which cannot receive mail anywhere.
No real child's information exists in it. Every center, family, child, address and phone number is invented, and the app labels it as such on every authenticated screen.

Walk the demo script →

Before a real center

What has to be true first

We wrote the bar down before we were anywhere near it, and we are not moving it to get a first customer. Four of the seven are now met.

Met The access rules run as server rules, with adversarial tests proving one family cannot reach another Deployed and tested.
Met The app is connected to that server, so the rules are the thing actually enforcing access Done for the data layer, and proven against the deployed project by a harness that signs up, creates a center, a room, a family and a child, checks in, records two updates, reads the boards back and checks out — 61 checks. The screens themselves have been driven against the emulator and the offline demo, not yet against the deployed project.
Met You can delete your own account from inside the app, and it runs Settings → Account → Delete my account, for every role. Deployed and driven against the live service: the deletion preview, the sole-owner refusal, and scheduling a center's deletion then cancelling it, all executed there for the first time in a 61-check run that found nothing. The purge runs on a two-minute schedule and has run clean since. Deploying it also found two bugs no local test could: an index that could not serve the purge's own query, and a cached center record that stopped the deletion banner appearing.
Not met The privacy and retention design is reviewed, and a center's exports execute The retention period itself is an open owner decision, and a request about a child's records is routed to the center for review rather than executed — which is deliberate, because the center holds the retention duty. A center's own export does not run yet.
Not met Backup, restore, incident response, monitoring and rollback are documented and drilled Not started.
Not met Terms, a privacy policy, a data-processing agreement and a subprocessor list receive qualified review Not started — see the draft notice on the terms and privacy pages.
Met Nothing in the demo, the screenshots or this website exceeds what the product does This page is how that is kept true.

Until all six are true, the honest offer is a conversation, not a contract.

Want to be an early center?

If you run an independent center and this is the shape of the problem you have, we would like to build the next phase with a real center in the room rather than a guess.

Get in touch See where the product is

Writing to us starts an email to support@cubbyloop.com. There is no form on this site and nothing is collected by this page.