Most Developers Don't Care About Customer Health. That Used to Be Fine.

Every SaaS company runs health checks on its servers every 30 seconds. Ask the same company how often it checks customer health, and the answer is usually:

During the monthly QBR, if someone remembers to pull the report.

Most developers don't think about customer health at all. It's not their problem. It lives in the CRM, which lives in the CS team's browser tab, which might as well be a different universe.

Servers are engineering. Customers are someone else's spreadsheet.

This made sense when the CS team was a cost center that sent renewal emails. It makes less sense now, when a customer who stops using your product costs you real money before they ever talk to a human.

The line between "technical health" and "customer health" has blurred. We just didn't update our tools to match.

Developers Built Infrastructure for Everything Except Customers

Here's what a typical SaaS engineering team monitors:

• CPU, memory, and disk I/O
• Request latency, error rate, and throughput
• Deployment success rate
• Database connection pools
• Cache hit ratios
• Queue depth

Here's what nobody monitors:

• Whether a paying customer completed onboarding
• Whether a customer who used the product daily for three months suddenly went silent
• Whether a trial user who invited three teammates is stuck because they can't connect an integration

These aren't soft metrics. They're leading indicators of revenue.

A customer who doesn't activate doesn't renew. A customer who goes silent cancels. The data already exists in your product database, billing provider, and support inbox. Nobody wired it together.

The reason isn't technical. It's cultural.

Why Developers Ignore Customer Health

It Was Never Framed as an Engineering Problem

Customer Success grew out of account management. The tools reflect that: CRMs, spreadsheets, and playbooks in Google Docs.

The assumption was that humans would do the evaluation, so the tools optimized for recording what humans decided, not for computing what's actually true.

Dashboards Are What the Market Built, Not What the Problem Needed

A real-time graph of "monthly active users" looks great in a demo. A deterministic state machine that computes customer_health = "at_risk" does not.

One is visual. The other is invisible until it fires. The market optimized for what demos well.

It's Uncomfortable

Server metrics are objective. CPU usage is CPU usage.

Customer health requires defining what "healthy" means. Getting three people in a room to agree on that definition is harder than wiring up a Prometheus exporter.

Developers gravitated toward the clean problem and left the messy one to the CS team.

But the cost keeps going up. SaaS companies with product-led growth don't have a CSM assigned to every account. Nobody is manually checking whether trial users are activating.

The product itself is the only thing watching. And right now, for most companies, the product isn't watching.

What Customer Infrastructure Looks Like

Your application already emits events:

• workspace.created
• integration.connected
• teammate.invited

Your billing provider fires:

• payment.succeeded
• subscription.updated

Your support tool fires:

• ticket.created
• ticket.resolved

Customer infrastructure ingests those events and continuously computes derived state.

Not a dashboard. State.

Example

Customer #42: activated

integration.connected ✓
teammate.invited ✓
first_value_event ✓ (day 3)

Customer #43: onboarding

workspace.created ✓
integration.connected ✓
teammate.invited ✗ (7 days, no invite)

Customer #44: at_risk

was: activated
inactive for 14 days
last event: login, Aug 1

The answer exists before you ask the question.

And it's deterministic. Given the same events and the same definition, you get the same answer every time.

No ML model that was 87% confident the customer might be at risk. No dashboard that renders differently because someone clicked a different date range.

A computation and a result.

Those rules live in version control. When "at risk" changes from 14 days of inactivity to 21, that's a pull request: reviewed, tested, and deployed.

The same pipeline as application code. Not a Slack message to the CS team, hoping everyone adjusts their mental model by Tuesday.

Where I Landed

I spent years in Customer Success before moving closer to engineering. One thing kept bothering me:

Application logic lived in Git repositories with pull requests and CI pipelines. Customer logic lived in spreadsheets with no version history and no way to know who changed what or when.

So I built Kite.

It ingests events from your existing stack and continuously computes customer state from rules you write in TypeScript.

import { defineLifecycle } from "@kitesdk/config";

export default defineLifecycle({
  initialState: "new",

  states: {
    activated: {
      enteredWhen: {
        journey: "onboarding",
        status: "complete",
      },
    },

    at_risk: {
      enteredWhen: {
        inactiveDays: 14,
      },
    },
  },
});

The workflow is:

kite init
kite validate
kite deploy

It feels closer to shipping infrastructure than configuring a dashboard.

If a customer isn't activated, the engine doesn't guess why. It reports exactly which conditions were satisfied, which were missing, and which events never arrived.

Whether Kite is the right answer is almost beside the point. The idea that customer health should be computed continuously, not reconstructed every time someone opens a dashboard, is what I'm arguing for.

A Takeaway You Can Use Today

You don't need Kite to start thinking this way.

Pick one customer state your team talks about constantly:

• Healthy
• Activated
• At risk

Write it as a boolean condition.

Not "they seem engaged." Not "I think they're doing well."

Write:

Activated =
  created workspace
  AND invited teammate
  AND connected integration within the first 7 days

Now show that definition to three people on your team and ask:

Does this match what you meant?

If they disagree, the problem isn't your tools. It's that your team has been using the same word to mean three different things.

No dashboard fixes that.

Infrastructure teams stopped querying server health manually years ago. They defined the rules once and let the system compute the answers.

Your customers deserve a health check too.