Case study · Senior care

BedAlly: from a blank repo to a launch-ready care platform in about three months

BedAlly, a senior-care placement startup in Phoenix, had the market insight and the relationships. It had no software and no facility network. I designed and built the platform, five apps on one shared core, and helped the team build the facility network and marketing it needed to go to market.

Book a free 30-minute call All case studies

~3 monthsBlank repo to launch-ready

5 appsOn one shared core

30 facilitiesProfiled across 27 operators

5 citiesLocal care guides published

At a glance

A launch-ready platform, and the network to fill it

BedAlly wanted to be the fastest route from a family’s first phone call to the right care community. I owned the product end to end, from design to operations, and worked on the go-to-market alongside the build.

Client	BedAlly, a senior-care placement startup in Phoenix, Arizona
My role	Lead engineer: product design, build, deployment, and operations
Timeline	May to September 2026
Built	5 apps: marketing site, operator console, admin back office, facility portal, and a behind-the-scenes service
Built on	Cloudflare, with a Postgres database, Resend for email, and Mapbox for maps
Outcome	Launch-ready, with 30 Phoenix facilities loaded. Shelved by BedAlly before launch over regulatory risk.

The challenge

Finding senior care is usually a crisis

A parent is leaving the hospital, and the family has days to find a place that takes their care needs, their insurance, and their budget. Getting them there fast meant serving three audiences in one system.

01 · Families

A simple way to ask for help

Families need a trustworthy place to start, at the worst possible moment.

02 · Placement team

Qualify, then decide

Staff qualify each family, often over the phone, and decide where to send them.

03 · Facilities

Referrals that fit

Facilities want qualified referrals that match their care types, payers, and location.

The BedAlly team had the market insight and the relationships. There was no software and no facility network yet.

What I built

Five apps on one shared core, all on Cloudflare

Families start on the marketing site. Placement staff work in the operator console, admins run the business from the back office, and facilities have their own portal. All five run on one shared set of business rules, hosted on Cloudflare.

Apps · who uses them5

01Marketing siteFamilies: care guides, intake, and the paid-social landing page

02Behind the scenesTakes in requests, maps locations, and runs nightly jobs

03Operator consolePlacement team: qualify, match, send, and phone intake links

04Admin back officeBedAlly admins: facilities, docs, and the error log

05Facility portalFacilities: their profile and the referrals they received

Shared coreUsed by all 5

MMatchingFit, distance, and fair rotation

GLocationDistance from any US ZIP code to every facility

DReferral deliveryBy email, or straight into a facility’s own system

ASecuritySign-in, access control, and abuse protection

EEmailConsistent, branded messages to families and facilities

Underneath2

DBOne databaseShared by all five apps, so everyone sees the same records

QDelivery queueKeeps retrying until a referral arrives

Because every app shares one core, matching and delivery follow the same rules wherever a referral is handled. Automated tests cover the rules that matter most: matching, rotation, and intake.

Beyond the code

A placement platform with no facilities in it is an empty room

So alongside the build, I worked on the go-to-market: the facility network, the content that brings families in, and the playbook the placement team runs on.

Building the business5

01A real facility networkI turned BedAlly’s Phoenix outreach list into 30 facility profiles across 27 operators, checking each against public sources, because several had been rebranded or renamed since the list was made.

02One-page facility summariesCare types, size, accepted payers, and highlights for every facility, researched from its own website, so staff had a one-pager for each conversation with a family.

03Local search contentCare guides for Phoenix, Mesa, Scottsdale, Peoria, and Chandler, each reviewed and fact-corrected before publishing.

04A paid-social landing pageWhen the team wanted to test social ads, I shipped a short-form landing page that fed straight into the placement queue.

05Operating playbook in the productThe placement team’s processes, documented inside the admin console and generated from the system’s live rules, so they couldn’t drift out of date.

The details

Where the details mattered

01 · Matching

Matching that’s fair, not just close

Ranking by fit and distance would have sent nearly every referral to the largest, best-located operators. BedAlly wanted volume shared. I rebuilt the ranking so the facilities with the fewest referrals in the last 30 days go first, with fit as the tiebreaker, and the rotation works inside a single operator too. I walked the team through the tradeoff before shipping: a qualified facility a little farther away can now beat a closer one that’s already busy.

02 · Intake

Intake that works from a phone call

Placement staff often take a family’s details over the phone, away from a desk. I built secure links that open a single family’s request without a login and expire after an hour. A mistake in the form used to wipe everything already typed; now it keeps every answer and points to what needs fixing.

03 · Production

A bug that only existed in production

Matching passed every local test, then failed in production. I traced it to a difference in how the live database connection returned some data, one the test setup never showed, and fixed it everywhere it mattered. Then I built an error log that records every failure across all five apps, searchable in the admin console, so the team didn’t have to wait on me to find out what went wrong.

04 · Delivery

Delivery facilities can trust

Referrals went out by email or straight into a facility’s own system, and retried automatically if a delivery failed. Every delivery attempt was logged with what was sent and what came back, so staff could see exactly what a facility received, and when.

Timeline

May to September 2026

1
May 2026

A blank repo

No software and no facility network. BedAlly brings the market insight and the relationships.
2
About 3 months

Five apps, one core

Marketing site, operator console, admin back office, facility portal, and the service behind them, built and launched on Cloudflare.
3
Alongside the build

The go-to-market

30 verified facility profiles, care guides for five cities, and a paid-social landing page.
4
September 2, 2026

Shelved, shut down cleanly

BedAlly decides not to launch. I back up the data, document the shutdown, and switch the platform off.

Shelved before launch BedAlly / 2026

It never launched, and the shutdown got the same care as the build

Late in the build, the team identified regulatory risk they couldn’t mitigate and decided not to go to market. The product wasn’t the reason.

I shut the platform down on September 2, 2026. If BedAlly ever wants to pick it back up, the data and records needed to restore it are on file.

Talk about your platform

More on my work in the sector: healthcare and healthtech.

Left on file3

01Full data backupVerified, with step-by-step restore instructions

02Shutdown recordEvery service and domain switched off, and what was deliberately kept

03Domain settings savedSo the site can be brought back on the same domain if needed

The result, judged

Blank repo to launch-ready platform in about three monthsPass
30 facilities across 27 operators, each checked against public sourcesPass
Shutdown backed up, documented, and restorablePass
Went to marketShelved by client

Your idea

Have the market insight, but no software yet?

If you know the market and have the relationships, let’s talk about what it would take to get from a blank repo to launch-ready, and to market.

Book a free 30-minute call What I build