The pivot: building for myself

Setup

After I shut down TallyCare, I sat with it for a while.

Months of work. Real infrastructure. A product that worked. And one customer who kept saying “soon” until I stopped asking.

The thing that kept nagging at me wasn’t the failure itself. It was the realization I’d had too late. I had been building for the staff in residential care homes. But the person with the most pain, the most motivation, and the most to lose wasn’t the staff. It was me.

I’m the conservator. I’m the one responsible for tracking everything about someone else’s life from the outside. Legal documents, court filings, medical history, dental appointments, eye exams, medications, behavioral changes, meals, incidents. There’s no system for this. There’s no app that handles the specific, ongoing job of being the person legally responsible for an adult who can’t fully manage their own affairs.

My current system is something I built myself: a mobile chat interface with a memory layer, attachments, appointment tracking, personal details. An agent that knows where to pull from. It works, mostly. But it’s fragile, expensive to run, and it gets lost in its own memory more than I’d like.

I decided to build something better.

What I tried

The architecture I wanted was agentic. A system that could remember context across conversations, surface the right information at the right time, and act more like a knowledgeable assistant than a search box.

I built it on top of a persistent memory system. The idea: log anything — a doctor’s appointment, a behavioral note, a medication change — and the agent would remember it, connect it to other things it knew, and answer questions about it later. When was the last dental visit? What medications changed in March? What did the regional center say at the last review?

In demos, in testing, in controlled conditions, it worked.

In practice, it kept breaking.

Where it broke

Persistent memory and long conversation context are genuinely hard problems. Not hard in a “I need to learn more” way. Hard in a “the tools aren’t quite there yet and the costs are punishing” way.

The agent would lose the thread. It would pull from the wrong memory. It would hallucinate details that weren’t there. And every conversation, every query, every correction was burning API tokens. The cost per user wasn’t theoretical. It was real, and it was high.

I don’t have the runway to eat that cost while I find customers. I already spent $4,000 on TallyCare and got nothing back. I’m not doing that again.

So I’m sitting with a tension I haven’t fully resolved: this problem is real and worth solving, and the architecture I want to build is too expensive to run at the price point that would make it accessible.

What clicked

I’m not done thinking about this. But here’s where I’ve landed.

The agentic layer is the wrong place to start. It’s the feature I want, not the foundation I need. What I actually need first is a reliable logger. Something that captures the right information, in the right structure, consistently. Medications. Appointments. Legal dates. Behavioral notes. The kind of thing that, if it existed and was well-organized, would make the AI layer much cheaper and much more accurate when I add it later.

Build the logger first. Make it useful without the AI. Then add intelligence on top of structured data instead of trying to build intelligence on top of chaos.

Go simpler. Go useful. Go now. The agentic piece can wait until the foundation is solid and the cost curve on these models comes down. It will come down.

Artifact

The app is in development. No link yet. But it’s real, it’s mine, and I use a version of it every week.

The memory system still exists in the codebase. I haven’t thrown it away. I’ve moved it to the side while I build the thing that needs to exist before it can be useful.

If you’re starting

Two things I’d tell anyone building in a space they personally care about.

Know the difference between what you need and what you think would be impressive to build. The agentic memory system was impressive. A reliable logger is what I need. Those aren’t the same thing, and confusing them is expensive.

On API costs: if your unit economics don’t work at the price you’d need to charge, that’s not a problem you can grow your way out of. Figure out the cost structure before you find the customers, not after.

The project is still alive. I’m still building. Just slower, and with a clearer sense of what done actually means.