Skip to content
Senior living playbook · No. 01

Buy vs. build the analyticsyour customers keep asking for.

A working guide for senior living software vendors. Work through it and you'll leave with the build priced honestly, three questions to put to your engineering lead, and a checklist you can take into any vendor conversation, including ones that aren't ours.

Free to read. No form. About a 7 minute read Forward it to your exec team
Start here

Where you are, in three numbers.

The senior living analytics gap, as of August 2026
54%
of the largest US senior living operators have zero data staff. When they can't build analytics themselves, the ask lands on their software vendors. That's you.
56%
of mid-market senior living software vendors have zero data or BI staff either. Most have the word analytics on their homepage right now.
3
category leaders already built or bought it: PointClickCare, Yardi, Aline. The gap between them and everyone else is what prospects notice in a bake-off.
So the question isn't whether your product gets a serious analytics layer. It's whether you build it, or embed someone else's under your own brand. The rest of this guide helps you decide.

Want the full picture of the category before you decide? See the vendor track page →

01 · Price it

Price the build beforeyour team commits to it.

Ask for the estimate in writing, then check it against this one. Most internal estimates price the visualization layer honestly and underprice everything beneath it.

A production analytics capability, the kind that survives contact with a 60-community operator, needs three things: a data platform, the team to run it, and an AI layer, because that's what your customers now mean when they say analytics. Stack Overflow's 2024 Developer Survey puts the median US back-end developer at roughly $170,000. With standard fully-loaded multipliers, one senior engineer costs $240K to $280K a year, and a credible first version needs about 1.5 to 2 of them.

What a first build costs
1.5 to 2 engineers
Year one
Work
Time
Cost
Visualization layerCharts, filters, layouts. The part that demos well, and the part most estimates get right.
1 to 2 months
~$60K
Multi-tenancy and row-level securityHardening, tenant isolation, the access model sitting under every query.
4 to 6 months
$90K to $160K
AI query layerWhat your customers mean when they say analytics. They've used ChatGPT.
4 to 6 months
$80K to $120K
First-year build total6 to 12 months
$150K to $340K
Then it keeps costing. Plan on at least 20% of an engineer, permanently, for schema changes, broken charts, tenant edge cases, and performance. Add answer evaluation on top if there's an AI layer. Over three years, teams that have done this land in the $470K to $740K range once the inevitable enterprise-tenancy rework arrives.

Compare the right two things. Not vendor fee versus free, but vendor fee versus two engineers, a year, and a permanent claim on your roadmap. For a vendor doing $10M to $30M, that's a material slice of engineering capacity spent on a capability that's someone else's core business.

If your estimate came in well under this, it's worth finding out what it left out. Three questions that surface it →

02 · Pressure-test it

Ask your engineering leadthese three questions.

The estimate covers building it. Keeping it truthful is the harder problem, and it's where in-house builds stall after the v1 dashboards ship. These three questions surface whether your estimate accounted for it.

You're not looking for a yes. You're looking for a mechanism. If the answers are confident but general, the expensive half of the work hasn't been scoped yet.

"We watched our offline accuracy drift from ~95% at launch to ~65% over a month before we treated this as an engineering problem."
Anthropic, on its own internal analytics agent. The cause: documentation going stale as the data model changed underneath it. Their conclusion was that strong data foundations are the most important part of keeping an analytics agent accurate. Read the post
Question 01 · Permissions

"How will a regional director's permissions be enforced when the AI writes the query, not the UI?"

Good answer

Names the mechanism, and offers to show you the same question asked by two different roles returning different data. Enforcement sits on every path a model can take to the data, not on the interface in front of it.

Vague answer

"The AI respects our permissions." That's the claim, not the mechanism. Dashboards are a solved problem; AI-written queries are not. Get this wrong in a market that handles resident health information and you haven't shipped an analytics feature.

Question 02 · Definitions

"When two dashboards disagree on occupancy, whose definition wins, and where does that definition live?"

Good answer

One place, owned by us, applied at the moment the question is asked, so the same question returns the same answer for every user on every surface. Unglamorous, and it's most of the work.

Vague answer

"It depends on the report." In senior living, close is worse than nothing. An occupancy number can feed a financing covenant, a state report, or a family conversation, and the first wrong one costs you every answer after it.

Question 03 · Drift

"Who runs the answer-accuracy regression suite after a model upgrade, and how many test pairs are in it?"

Good answer

A named owner, a standing suite of known question and answer pairs run continuously, and a human process for triaging drift when the numbers move.

Vague answer

Any version of "we'll test it before launch." Models change under you and schemas drift. This is the single most underestimated line item in every build plan, and it's why "AI insights" sits on the roadmap for three straight quarters.

Got your answers? Now check them against what each path requires. Work through the conditions →

03 · Decide

Check what you actually have.

No score, and no verdict from us. These are the conditions each path needs. Read them, count your own boxes, and notice where a column runs out.

Build

Own the whole stack

  • Analytics is your core product, not a module wrapped around one. If insight is what you sell, owning the stack is strategy.
  • You have, or will genuinely fund, a data team with a leader who has shipped production analytics before.
  • Your roadmap and your board can absorb 6 to 12 months and $150K to $340K before customers see anything.
All three, or the build stalls after the v1 dashboards.
Embed

Ship it this quarter

  • Analytics is a feature your customers demand, wrapped around a different core product.
  • Your data team is small or nonexistent. If you're one of the 56%, this is you.
  • There are bake-offs happening this quarter where this is the gap.
Two of three is usually enough. This is where most of the mid-market lands.
Both, in order

Keep the dashboards, add the layer

  • You already shipped reporting, and it proves you know the workflows better than any general tool does.
  • What customers ask for now is plain-English answers, not more charts.
  • You'd rather hire the data team later, from revenue, once the capability is already earning.
Keep what you built. Add what they're actually asking for.

If a column came up short, the next conversation is with vendors. Here's what to demand from them →

04 · Evaluate

Take this into everyvendor conversation.

This works for any vendor, including ones that aren't us. It's built from what end users in senior living keep asking for after their software already shipped reporting, which is the pattern worth paying attention to.

Ask for a live demo of each one. Don't accept the claim.

Can a non-engineer add a new view, without filing an engineering ticket?
Ask to watch someone do it live, start to finish. What end users in this category keep describing is report-building confusing enough that every new question goes back to a technical resource. If the answer is a services engagement, you've bought a backlog.
Can your customers export what they're looking at?
Unglamorous, and it's the one that generates support tickets. Users in this category still export to spreadsheets to do the analysis the tool was supposed to do. If export is missing or awkward, you won't hear it from the vendor. You'll hear it from your own customers.
Does it handle data spread across products that were acquired separately?
Senior living software grew by acquisition and the analytics layer usually didn't follow, which is why so many stacks are stitched together. Make the vendor answer for your actual data shape before signing, not during implementation.
More items are being added to this list as we finish a review of what vendors in this category actually document, including how row-level security is enforced on AI-written queries and who owns answer accuracy after a model upgrade.

Whichever way the checklist goes, the first move is the same. Start with your own data →

05 · Start

Before it's a build decision,it's a data question.

Both paths assume the data you're sitting on can actually power an analytics product. That's worth checking before you spend a quarter or sign a contract.

Start with one export, or challenge us with as many sources and connectors as you'd like. More sources means the report can show how your tables connect across systems and where the joins break. In 3 to 5 business days Querri sends back a branded 4 to 5 page report on what's clean, what's broken, and the questions your customers could already be asking your product. It's free and it's yours to keep either way. Your file comes back or gets deleted on request.

SOC 2 Type II ISO 27001 HIPAA-ready

Your product already has the data.Find out what it can support.

Start with one export, or challenge us with as many sources and connectors as you'd like. In 3 to 5 business days you get a branded 4 to 5 page report: what's clean, what's broken, and the questions your customers could already be asking. Free, and yours to keep.