I built it four times and shut it down

Setup

When someone close to me needed a residential care home, I got pulled into a world I didn’t know existed.

These homes are hard to find. They operate differently from each other. Staff are underpaid and overworked, and turnover is high enough that the people who actually know your family member are gone before they’ve had time to matter. The state of California manages a $22 billion budget for services in this space, routed through regional centers that act as intermediaries. The funding is inconsistent. Approvals depend more on relationships than on documented need. Data lives in paper binders and people’s heads.

I became the legal conservator for my family member. The person responsible for their care, their decisions, their life. And I started keeping a list of everything that was broken.

The gap I kept coming back to: the staff in these homes had no good way to log what was actually happening. Medications, meals, behaviors, appointments, incidents — all of it tracked manually, inconsistently, or not at all. A simple tool to log on the fly, from wherever they were, would produce better data. Better data meant better care. Better care meant better outcomes for the people who needed it most.

I called it TallyCare.

What I tried

I built it four times.

The first version I built with ChatGPT as a coding coach. Slow, instructional, a lot of copy-paste and prayer. It taught me what I didn’t know, which was most things.

The second version I built with v0. One prompt, a real interface. I remember thinking: this is what I was trying to describe. But v0 gets you to a demo, not a product.

The third version I built in Cursor. This one started to feel real. A proper codebase, an agent that could read across the whole project, actual architecture decisions to make.

The fourth version I built with Claude Code. By this point I knew what I was building. The stack was cleaner. The decisions were better. I got into starter programs with DataDog, AWS, and Aptible, which gave me infrastructure headstarts that would have cost thousands otherwise. I built HIPAA compliance in from the start. I deployed it. I had a real app.

Where it broke

The app worked. The market didn’t.

I had one customer — the home where my family member lives. I had conversations with others. People asked questions. People said it sounded valuable. Nobody implemented it.

I kept going back to my first customer. I asked again. I followed up. I offered to help with onboarding. I made it easier. I asked again.

At some point I realized I was begging. Not pitching. Begging. And the answer I kept getting wasn’t “no.” It was something worse: a “yes, soon” that never arrived.

These homes are genuinely overwhelmed. Staff don’t have time to learn new software. Operators are managing crises daily. Introducing a new system, even a simple one, even a free one, requires someone to champion it, train on it, enforce it. Nobody had the bandwidth.

I had burned about $4,000. I wasn’t going to burn more.

I pulled the plug.

What clicked

There’s a difference between a problem people acknowledge and a problem people will change their behavior to solve. Everyone I talked to agreed the data problem was real. Nobody was willing to add one more thing to their day to fix it. That gap, between “yes, this is a problem” and “yes, I will do something about it,” is where most B2B products go to die.

The other thing I realized, too late: I had been building for the staff when the person with the most pain and the most motivation was me. The conservator. The family member trying to track everything from the outside. I wasn’t the operator. I was the customer.

That pointed somewhere new.

Artifact

TallyCare is offline. The code still exists. The HIPAA compliance work, the AWS architecture, the DataDog integration — all of it is sitting in a repo.

I don’t think the B2B idea was wrong. I think the timing was wrong, and I was the wrong person to sell it. Selling into residential care facilities requires relationships I don’t have and a sales motion I’m not built for. Maybe someone else picks this up someday. Maybe I come back to it.

For now, I took what I learned and pointed it somewhere else.

If you’re starting

If you’re building something and your first customer keeps saying “soon,” pay attention to that. Not because they’re lying, but because “soon” in a busy environment usually means “never, unless you make it impossible to say no.”

The question isn’t whether the problem is real. The question is whether the customer is ready to change. Those are two different things, and you need to know which one you’re dealing with before you spend another month building.

Get a real customer or get out early. The longer you wait to hear the honest answer, the more it costs.