Availary

Inspiration

Finding childcare is not really a search problem.

Parents can find dozens of centers on maps and directories, yet still have no reliable answer to the question that actually matters:

Will there be a place for my child when I need care?

Availability changes constantly. A center can be full today but expect an infant opening next month. Another may only have Tuesday and Thursday availability. A waitlist may exist without giving a family any useful idea of when a place could open.

The normal workflow is still surprisingly manual: shortlist providers, call them, take notes, remember when each answer was given, and call again later.

We built Availary to turn that phone work into a living view of childcare availability.

What it does

Availary helps a parent create a care need based on details such as:

the child's age at the requested start date
desired start date
required weekdays
full-time or part-time care
selected childcare providers

When the parent wants fresh information, Availary prepares a bounded availability check and, after explicit approval, uses CALL-E to call the provider.

The call asks only the information needed to evaluate the care need, such as:

whether an appropriate age group currently has space
whether an opening is expected later
the earliest reported opening window
which days are available
whether the waitlist is open
whether a tour or callback is available

CALL-E returns structured results and evidence from the conversation.

Availary then converts that result into a timestamped Capacity Observation.

A Capacity Observation is not treated as permanent truth. It records what a provider reported, when they reported it, how well it matches the family's requirements, and when that information should be considered stale.

That lets Availary show states such as:

Open now
Expected opening
Partial fit
Waitlist only
No fit
Unknown

Most importantly, Availary preserves uncertainty. A missed call, refusal, voicemail, or unsupported answer never becomes "no availability."

The Radar

The core product is the availability timeline.

Instead of showing childcare providers as a static comparison table, Availary shows how their availability changes over time.

A provider can move through a history such as:

WAITLIST → EXPECTED OPENING → OPEN

Parents can see:

when each provider was last checked
the reported opening window
whether the schedule matches
whether the information is fresh or stale
the evidence supporting the observation
how the provider's state changed between checks

This makes Availary useful after the first call instead of becoming another one-time search result.

How we built it

Availary is a responsive web application with a clear separation between the consumer product and the phone infrastructure.

The frontend provides the care-search workflow, provider shortlist, availability Radar, observation history, evidence views, and call approval experience.

The backend owns authentication, persistence, domain validation, and live call execution.

For a live check, the flow is:

Care Need → Call Preview → User Approval → CALL-E → Structured Result → Evidence Validation → Capacity Observation → Compatibility + Freshness → Radar

We use CALL-E because the information Availary needs often lives behind a real phone conversation rather than an API.

The integration uses CALL-E's Developer API from a trusted backend. API credentials are never exposed to the browser.

We use strict structured-result schemas and preserve unsupported or unclear values as unknown rather than guessing.

The application also has a fixture/demo path so the complete product can be explored without triggering a real phone call.

Safety and user control

Phone calls can create real-world side effects, so Availary keeps the user in control.

Before a live call, the parent sees exactly what will be asked.

Availary does not need to disclose a child's name, medical information, payment information, or other unnecessary personal data in the initial availability check.

The first call only gathers availability information.

Availary does not automatically:

enroll a child
pay a deposit
sign a contract
reserve a place
make commitments on the parent's behalf

Any later action such as requesting a tour remains a separate, user-approved step.

Challenges we ran into

The hardest part was realizing that childcare availability could not be modeled as a simple yes/no field.

Availability depends on several dimensions at the same time:

child age at the requested date × classroom age band × required weekdays × start date × opening window

We also had to separate phone-call execution state from childcare availability state.

A successful CALL-E task does not mean a provider has an opening, and a failed or unanswered call does not mean a provider is unavailable.

That led us to build an explicit observation and validation layer between CALL-E and the user-facing Radar.

Another challenge was designing the product around information that naturally expires. Rather than overwrite old answers, Availary preserves observation history and makes freshness visible.

What we're proud of

We're most proud that Availary is not simply "AI that calls businesses."

The phone call is one part of a larger product mechanism.

Availary turns changing offline information into a time-aware record that a parent can actually plan around.

The result is a product where the most important moment is not the call itself, but seeing a provider change from:

Waitlist → Expected opening → Open

with the evidence and timestamp behind that change.

What we learned

Building Availary reinforced that real-world agent products need to distinguish between:

what was asked
what was actually said
what the model extracted
what the application can safely conclude

Structured extraction is useful, but product logic still needs to decide what counts as trustworthy and actionable.

We also learned that uncertainty is part of the product.

Showing Unknown honestly can be more useful than generating a confident but unsupported answer.

What's next

The next step for Availary is expanding the Radar from manually selected providers into a broader childcare planning workflow while keeping the same evidence and freshness model.

Potential directions include:

user-controlled recurring rechecks
notification when a provider moves into a compatible opening window
provider discovery
tour-request follow-ups
shared searches between parents or caregivers
broader offline capacity use cases where availability changes faster than public directories

The core idea remains the same:

Childcare directories tell you where care exists. Availary helps you see when a place may actually open for your child.