I didn’t plan to build familychildcaresf.com. I built it five times, and each time it became something different from what I intended.

I’m writing the journey down because I think the shape of it might be familiar to other community advocates building things — and because the most useful version of the project ended up being something I would have rejected if I’d planned for it from day one.

v0 — The personal tool

It started as a tool for me. My mother has run a small family child care home in San Francisco since 2010. I wanted to know what was actually going on in the SF family child care market — how many programs, where, which were ELFA-funded, which had subsidies, which were closing.

Some of the data existed in public records. CCLD licensing tells you who is licensed and at what capacity. DEC contract lists tell you who is funded under ELFA. R&R rosters tell you who’s in the referral pipeline. Read the provider names carefully and you can even infer, roughly, what languages a program likely serves. What none of those public sources tell you is whether a program is doing okay — whether it’s full, half-empty, or quietly closing. That dimension only lives in the providers’ own knowledge, and historically nobody has been asking them at scale.

So I started connecting what was public, while keeping a note on what was missing. Not to publish anything — just to understand what I was looking at when I went to a board meeting.

v0.5 — “Might as well share”

The “might as well share” stage was inevitable. Once you’ve built a thing for yourself that answers questions you keep being asked, the choice is either to keep emailing CSVs or put it on a webpage.

So I put it on a webpage. The first public version was a program-level vacancy projection tool — a small forecaster a provider could use to see when their own program would have openings over the next twelve months, based on each enrolled child’s age-group transitions, expected departures, and kindergarten start. Not a system-wide supply model. Just a way for one provider to see their own next opening before a parent asked.

v1.0 — The pivot to registry

The projection tool was useful for the provider running it. It didn’t help the actual problem in front of me.

The actual problem was this: my mother’s program was always full. We kept getting calls from families we couldn’t serve. Every week I was forwarding those calls by hand — texting other FCC providers in the network one by one, asking “do you have an opening right now?”, waiting for replies, then circling back to the family. The same conversation, repeated, every week.

I wanted two things at once. I wanted families who called us to land somewhere — a list of FCC programs in their neighborhood, in their language, that they could call directly. And I wanted to stop being the manual switchboard. If providers kept their own openings up to date in one place, I could just send the family a link.

So I pivoted. I used Claude to take the old paper-listing model that R&R intake centers used and rebuild it as something more systematic — searchable, mobile-friendly, real-time, in three languages (English, Spanish, Traditional Chinese). familychildcaresf.com 1.0 was a registry, not a model. It listed providers. It let providers report their own vacancies. It let parents search by neighborhood and language.

The vacancy-reporting layer is the part I want to underline, because it’s the part I missed communicating in earlier projects. Public records can already tell you a program’s licensed capacity. They cannot tell you whether that capacity is full or empty right now. The registry’s vacancy field is my attempt to supplement what public data can’t show — to surface the dimension only providers themselves can speak to: are they doing okay, are they full, do they have room.

That version landed. Real providers signed up. Real parents called real numbers. And the manual switchboard work mostly went away.

v1.5 — Why I keep building it

I want to be clear about something. The “deeper purpose” of the registry isn’t a strategy I uncovered after the fact. It’s not a secret layer underneath the listing. It was upfront from the beginning, because it’s the same reason I show up to most things in this community: I’m a facts person. I don’t want to argue from hearsay.

I’ve been engaged in this community long enough to know what people need and what’s missing. I’ve also sat in enough meetings to know that when providers describe their reality in their own words, policymakers tend to discount it as anecdote. Numbers don’t get discounted the same way. So when I build something like the registry, part of what I’m doing is creating a place where providers self-report their own perspective in a structured way — and I bring those tables into the room when we’re advocating, so the conversation isn’t “Oscar says” but “here is what 372 providers reported themselves.”

That’s the role I want this tool to play for the association. Not a power play. Concrete examples. A way to show the facts of what providers are surfacing about their own programs that they may never get to say in a policy meeting on their own.

And honestly, the goal underneath all of that is to push the R&R community to do this kind of work themselves — to use the data they already hold in a meaningful, useful, contributing way, instead of holding it. If they did that better than I can, my tool becomes obsolete. That’s fine. If the system gets to a place where this kind of transparency is normal for the community, then this project has done what I wanted it to do.

v2.0 — When the data tells you something you didn’t ask

This week, working through the registry data with Claude, I started building something I’m calling the Pressure Lens — a view that joins two layers: licensed capacity from the public roster, and self-reported vacancy from the registry. The first cut segmented by language, and the picture it returned was uneven enough that I almost wrote a sharp post about it.

I’m glad I didn’t, because the first signal it surfaced wasn’t really about the SF market. It was about my own outreach. The Hispanic provider segment in my registry is thinner than the Hispanic provider segment in the public roster. So a “Spanish-speaking families have no visible openings” reading from the registry alone reflects a gap in who I’ve reached, not a gap in who exists. The right next step is to take the full provider list from the public sites, infer language from provider names, and ground the language segmentation in the full population — then compare against what the registry’s self-reported vacancy data shows for that same population.

The honest payoff of this stage isn’t a finding. It’s the lens itself. Public data can tell you who is licensed and at what capacity. Only self-reported vacancy data can tell you whether that capacity is doing okay. Joining those two layers is the question the registry made askable. Acting on the answer responsibly means first checking whether what I’m seeing reflects the city or reflects me.

When the joined-roster analysis is grounded, I’ll write up what it shows about the 750-slot ELFA expansion and the ranking criteria — particularly whether language and geographic equity belong in the points. That’s the next post.

What the journey teaches

Five things I’d tell another community advocate building something similar.

The first version is for you. Don’t try to build for “the community” before you’ve built something for yourself. You don’t yet know what the community needs from you specifically — and trying to design for everyone first usually produces a thing nobody uses.

Pivots are signals, not failures. Each time I shifted, it was because the version I had was solving a smaller problem than the one actually in front of me. The projection tool wasn’t wrong — it still lives inside the registry today, helping individual providers see their own next opening. It just wasn’t the thing that would stop me from being a manual switchboard between families and providers. The pivot was the data telling me what the bigger job was.

A tool can do more than its stated function — and you can say so out loud. familychildcaresf.com is a vacancy registry. It is also, openly, a way for the FCC association to bring concrete, self-reported provider data into rooms where our community is usually represented as anecdote. I never treated the second purpose as hidden. It’s been upfront from the beginning, because that’s how I want this kind of work to be done — visibly, on the record.

Bring numbers into rooms where you’d otherwise be argued with. Providers’ lived experience gets discounted as hearsay; tabulated, self-reported data doesn’t. Building your own data pipeline — even a small, partial one — changes what you can say in a meeting. You stop arguing from “trust me” and start arguing from “here is what providers reported themselves.”

The data eventually tells you things you didn’t ask it — and the first thing it tells you is usually about you. I built the registry to match parents to providers. The first time I tried to read it as a market lens, it told me my own outreach into the Hispanic provider community has gaps I haven’t closed. That’s a finding too. Before the registry can tell me anything reliable about San Francisco, I have to be honest about what it’s currently telling me about my own reach. The infrastructure outlasts its original purpose, but only if you let it correct you first.

An invitation

If you’re an advocate or a small-org leader building something for your community, and any of these stages sound familiar — the personal tool stage, the “might as well share” stage, the pivot to the bigger problem, the moment the data tells you something new — I’d like to hear from you.

The technology isn’t the hard part. The harder part is recognizing when you’ve moved between stages and what to do next.

If any of this is useful to you, or if you want to compare notes on a parallel journey in your own community, reach out. I don’t have answers. I have a journey, and I’m always trying to find people walking parallel ones.