How We Built a Portal for 100+ Early Intervention Providers on Top of Airtable

Homefront Family Services is Indiana's leading First Steps early intervention provider. First Steps is a state program for children under three with developmental delays. The providers in this network document everything: session notes, progress toward IFSP goals, attendance, billing codes. The paperwork load is real and it compounds fast across a team.

We built them a custom admin portal. Here's what we learned.

Why Airtable Was the Right Starting Point

Homefront already ran their operations in Airtable. Client records, provider schedules, case notes, all of it. Ripping that out and standing up a relational database would have meant a migration project, a data cleanup project, and a training project before we ever shipped a single feature.

We didn't do that. We built the portal on top of the Airtable they already had.

The tradeoff: Airtable's API is slower than a database you own. Rate limits are real. You can't join across tables the way you would with SQL. If you build naively, the portal feels sluggish and the team stops using it.

So we didn't build naively.

The Caching Layer

Every read-heavy view in the portal goes through a cache. When a provider loads a client record, we serve the cached version immediately and revalidate in the background. Airtable sees a fraction of the requests the portal would otherwise generate.

This matters for two reasons. First, it keeps the UI fast enough that providers actually use it during sessions rather than after. Second, it keeps the portal well under Airtable's rate limits even as the team scales.

The cache isn't magic: it has to be invalidated correctly when records change. We tied invalidations to the write path so stale data doesn't persist past the next reload.

Optimistic Save UX

Early intervention providers don't always have great internet. Rural Indiana is not San Francisco. A provider saving session notes in a client's home can hit spotty coverage mid-form.

Optimistic-save means we write to local state immediately, show the provider the save as confirmed, and sync to Airtable in the background. If the sync fails, we surface it, but the provider isn't blocked. They've already moved on.

This is a small thing that changes whether a tool feels trustworthy. A spinner that hangs, then fails, trains people to save their work in a separate document first and paste it in later. That's the behavior we were trying to eliminate.

The AI Layer

The part that erases hours of admin per week is the AI-assisted case documentation.

First Steps providers write a lot of the same kinds of notes. A session with a toddler working on gross motor development looks similar across weeks. The language has to be precise for billing and for IFSP compliance, but the structure is repeatable.

We built AI-assisted drafting into the note workflow. The provider fills in what happened: what they worked on, how the child responded, what they'll target next. The assistant turns that into a structured note in the format the program requires. The provider reviews, edits, and saves.

This is not AI replacing documentation. It's AI handling the translation from what the provider knows to the format the system requires. The provider still makes every clinical judgment. The assistant handles the formatting and the language that has to match a template they've seen a hundred times.

The result is providers spending less time writing the same kinds of sentences and more time doing the work the program exists for.

What's Actually Live

The portal is in production with 100+ providers across Homefront's network. Airtable is still the source of truth. The cache sits between it and the portal. Saves are optimistic. AI drafting is built into the session note flow.

The same infrastructure pattern, an API you don't own, a caching layer, optimistic saves, an AI assist layer on top, is what we built for Freedom Ag Supply with their weed-identification assistant. Different industries, same shape.

If your organization runs on a tool like Airtable and the thought is "we need to migrate before we can build anything real on top of it," that's not always true. Sometimes the caching layer is faster to ship than the migration, and you can revisit the database question when the portal has proven its value.