There was never a single moment. No crisis, no emergency, nothing that would make a tidy opening scene.
What there was instead was a question that came up every week for years. Who is taking the kiddo to his sporting events? Who is taking him to Scouts? My wife and I would sort it out, usually over text, usually twice because one of us had forgotten the first conversation. Then my dad started needing more help, and the same question showed up with higher stakes attached to it. Who is taking him to the appointment on Thursday.
That is the thing about caregiving load. It does not announce itself. It accumulates. Nobody files a support ticket for ambient dread, which may be why so little software gets built for it.
I wanted help. I wanted to share the burden and lower my own cognitive load. So I decided to build something, and I called it App4Dad. App4Mom was the version for moms.
Five months later, the AWS account is empty.
What Calendars Never Tell You#
Modern calendars and email are good at what and when. They are sometimes good at who, in the narrow sense that they will happily list six people on an invite. What they will not tell me is which of those six is actually going to do the thing.
“Who’s got this?”
That was the whole idea. An invite for a doctor’s appointment with three siblings on it carries no information about which sibling is driving. A shared family calendar with a Scouts meeting on it has no idea I am out of town that week. The data needed to answer the question is already sitting in the calendar and the inbox. Nothing reads it, and nothing models intent.
What App4Dad Did#
App4Dad synced a person’s email and calendars every 30 seconds, on the device, and turned them into a picture of what was coming up. There was a daily view, a weekly view, and a monthly view. Every task and calendar invite had an “I’ve got this” button. Tapping it claimed the item, and the claim synced to whoever that person had chosen to share with. Nothing was assigned automatically, and sharing with another person was opt in.
There was also a chat where a person could ask “What are the next ten things coming up?” and get an answer. The chat ran behind Guardrails, so a person in a mental health crisis got the actual numbers for help. Once someone opted in to AI, they also got daily and weekly notes.
It worked for me. It kept me on top of the bills. It told me when events were coming up. It even caught birthdays.
Privacy As A Primitive#
I went through my employer’s conflict of interest process first, got clearance, and gave Nidus Labs a go.
The thesis had two halves. The first was that AI could genuinely improve quality of life for people in caregiving situations. The second was that the privacy had to be structural rather than a policy page.
So the architecture worked like this: observations pulled from a user’s email were extracted on their device and stored in a local SQLite database. To get that data from a phone to a laptop, every change became a client-encrypted patch in an append-only log, with the local database acting as a cache that could be rebuilt by replaying the log from scratch. The key was derived from the user’s password and never left their devices. The server held ciphertext and metadata, stored in S3.
In sync and storage, I could not read my users’ data. That was the design goal.
Everything was consent driven. Sharing with another person meant opting in. Using the AI features meant opting in to several permissions, each one explicitly, and the chat model saw the data the client sent in from its SQLite ledger only after that. Those consent records lived in an encrypted DynamoDB table. The decryption key was not available to any admin, so only the service itself could read them.
A caregiving app sees things that are nobody else’s business. A parent’s diagnosis. Which sibling stopped showing up. The appointment nobody in the family wants to discuss. It gets intimate fast. I built the thing to help people and not to exploit them for commercial purposes, and I wanted that to be true at the level of cryptography instead of the level of a promise.
It cost real time. Recovery alone needed a triple lock, because “only you can decrypt this” and “I lost my phone” are genuinely difficult to satisfy at the same moment. I wrote 144 architecture decision records for this project, and most of the interesting ones are about keys.
Then September 18th Happened#
On September 18th, Google announced CC, an AI agent that works across Gmail, Calendar, Chat, Docs and Drive to help a household coordinate. It handles permission slips, activity registration, shopping lists and meal plans, for up to six family members. Google’s own framing talks about keeping up with kids’ school schedules and sports practices.
That same day, Meta shipped Muse for Mac, which acts across files, calendar, notes and messages. Free download.
I have not used either product, so I am not going to pretend to a comparison I never ran. What I can say is that the published description of CC sits close enough to my own product sheet that reading it was a peculiar experience.
The day after, I wrote the architecture decision record to tear down my AWS infrastructure.
That timing is mostly coincidence. The decision was already moving. Four days earlier I had deferred a passkey feature on the explicit grounds that with one real user and a working sign-in, more building added no value. The teardown record cites cost and the absence of a roadmap. It does not mention Google anywhere.
A Feature, Not A Moat#
The part I was slower to say out loud is that “who’s got this” is a feature, and a simple one for a calendar application to add.
Google has not shipped it yet. Nothing in CC’s published material describes assigning a specific action to a specific person, so the gap I found is technically still open. It is open the way a door is open when somebody much larger is already walking toward it. Google and Meta have both built something in this space, with full engineering and go to market teams behind it. I had a genuine insight and no defensible position. The gap will close, and it will close on their schedule.
One distinction does hold up. CC runs on an isolated cloud computer and lets each family member choose what to share. That is permissioned sharing, and it is a different trade from the one I was offering. Google can read it. Free has a price, the price is the data, and that was the one competitive move my architecture had deliberately made impossible for me.
I was differently positioned, and the market did not care.
The Part That Had Nothing To Do With Google#
I had five users. One of them was me. The others were friends in precisely the situation I had built for, coordinating care for aging parents, who knew me personally and had every social reason to give it a fair try.
They signed up. They did not use it.
Distribution gets people to the door, and these people were already standing in the house. Reach was never the problem.
I do not know why. The usage data was encrypted and I never tried to mine it, so the privacy design did exactly what I built it to do and left me one way to find out, which is to ask. I have not asked them yet. That is an uncomfortable sentence to type. Five months of building, and I never ran the one conversation that would have told me what was wrong.
Here is my hypothesis, and it has not been tested. The app worked for me because I built it and knew what every piece was for. A new person had to opt in to several separate permissions, create a password, connect their email and calendars, and opt in again to share with each person they wanted to coordinate with. People have learned to expect AI products to work on the first try with almost no setup, and App4Dad was probably too much product for that expectation.
What Five Months Cost#
August 2026 came in at $153.74. The first nineteen days of September were $89.30. Call it $140 to $155 a month, somewhere near $1,800 a year, and almost all of it fixed cost for keeping a production topology alive rather than anything to do with usage. Fargate, a NAT gateway, a load balancer, a handful of public IPv4 addresses.
144 architecture decision records. 307 specifications. 742 closed issues. Five users.
That ratio is the most honest number in the project. I love building, building was a real part of the joy here, and it is entirely possible I let it become more of the point than I would have admitted at the time.
Google and Meta handed me permission to stop. The ledger had already made the case.
What I Am Keeping#
The repository gets archived rather than deleted, because git history is not billed and it is the rebuild path if I ever want one.
What I want to do next is open source the client-side cryptography. The vault, the password-based key derivation, the encrypted sync log, the recovery design. It is a self-contained library with no AWS anywhere in it and a dependency list I trust. Most products that claim client-side encryption stop at encrypting on the device and never solve multi-device, recovery, or sharing. I solved all three and then switched the product off, which seems like a waste of a working answer.
Nidus Labs isn’t about money. I would like to build something people pay for, enough to cover the infrastructure and the bills, and then keep building things that help people in the intersection of software and AI. That is the entire ambition.
I would like to hear from anyone who tried a tool like this and found that it stuck or did not, because that is the conversation I skipped. If an open source client-side encryption library that handles multiple devices, recovery, and sharing would be useful, I would like to know what it needs to do. You can find me on LinkedIn.
I Am Not Done#
App4Dad and App4Mom are finished. Product market fit was the gap I never closed, and Big Tech arriving made the decision easy. Nidus Labs keeps going.
I learned a lot from building them. I found an idea that inspired me, went after it, and applied everything I have learned over more than a decade of software engineering. I now know where the rough edges are with models and what they can and cannot do. This is a pivot. I will find the next idea, work hard to make sure it fits a real need, and bring it to market early.
Keith