DEV Community: Mateus Victor

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

Mateus Victor — Tue, 04 Aug 2026 14:23:50 +0000

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.

Your servers have a runtime. Your customers don't. That's the gap

Mateus Victor — Thu, 30 Jul 2026 17:06:10 +0000

Why the query model works for analytics and fails for customer health — and what a runtime model looks like in practice.

Most dev founders I know can tell you their p99 latency from memory. Far fewer can tell you how many paying customers got stuck in onboarding this week.

That isn't because they care less about customers. It's because we built infrastructure around continuous evaluation while customer operations remained stuck in the query era.

Every few seconds, Prometheus evaluates alerting rules against incoming metrics. CI pipelines execute automatically for every commit. Monitoring systems don't wait for someone to ask whether a service is healthy. They continuously compute the answer and notify you when something changes.

Customer state works very differently. To understand where a customer is, someone opens an analytics dashboard, checks the CRM, compares billing information, and pieces together events from multiple systems. By the time an answer exists, it's already a snapshot of the past.

The gap between infrastructure monitoring and customer monitoring isn't primarily a tooling problem. It's an architectural one.

Two ways to answer a question

There are two fundamentally different ways to answer questions about a system.

The first is to execute a query when someone asks a question. The system retrieves historical data, computes the result, and returns an answer. This approach is ideal for exploratory analysis. If you want to know how many signups came from Germany during Q2 or which feature grew the fastest over the last month, running a query is exactly the right solution.

I'll call this the query model.

The second approach is to define the important states ahead of time and continuously evaluate them as new events arrive. Instead of computing an answer only when someone asks, the system keeps the answer up to date at all times.

I'll call this the runtime model.

By "runtime," I don't mean a programming language runtime. I mean a system that continuously evaluates business rules and maintains derived state from an incoming stream of events. Prometheus continuously evaluates alerting rules. CI pipelines continuously evaluate every new commit. A customer runtime follows the same idea.

Neither model is universally better. They solve different problems.

The query model excels at answering questions you couldn't predict in advance.

How many signups came from Germany last quarter?
Which feature grew the fastest this month?
Which pricing plan converted best?

The runtime model excels when the question has a stable definition and the answer is operationally important.

Is the database healthy?
Did the deployment succeed?
Is this service available?
Is this customer activated?
Is this customer at risk?

Those aren't questions you want to investigate manually every hour. You define the conditions once and let the system maintain the answer continuously.

I think customer state belongs in this second category.

What a customer runtime looks like

Imagine you're trying to determine whether a customer has successfully activated.

Your application already emits the relevant events.

workspace.created
teammate.invited
integration.connected

In a query based workflow, someone periodically checks whether each customer has completed those steps. The answer only exists at the moment the query runs. Tomorrow someone needs to repeat exactly the same process.

In a runtime model, the rule is defined once.

A customer becomes Activated after all three events have occurred.

From that point on, the system watches incoming events continuously. The moment the final condition becomes true, the customer's state transitions to Activated. Every consumer, whether it's an API, a dashboard, or an automation, reads exactly the same current state.

This isn't a new architectural pattern. It's the same principle behind state machines, monitoring systems, and CI pipelines. A finite set of inputs produces a deterministic state. New input arrives. State changes. Everyone reads the current truth.

We already use this pattern throughout software infrastructure. We just haven't applied it consistently to customer operations.

Building a customer runtime

If you wanted to build this yourself, the architecture is surprisingly straightforward.

First, you need an event ingestion layer. Your product, CRM, billing provider, and support platform already emit events through webhooks. Receiving them isn't difficult. The real challenge is normalizing those events into a consistent schema that business rules can understand.

Next comes a deterministic rules engine. Every incoming event is evaluated against the rules that depend on it. A completed onboarding step might update activation status, lifecycle stage, health score, and several other pieces of derived state at the same time.

Determinism is essential. Given the same sequence of events and the same rule definitions, the engine should always compute exactly the same result. Without determinism, debugging becomes difficult, versioning becomes unreliable, and trust disappears.

The output isn't another dashboard. It's computed state.

Customer 42 → Activated
Customer 43 → Onboarding
Customer 44 → At Risk

Each state should include evidence showing which conditions were satisfied, which weren't, and which events produced the result.

Finally, those rules need versioning. Customer definitions change over time. Maybe activation requires one more onboarding step. Maybe an at risk customer becomes inactive after 21 days instead of 14. Those changes are business logic, and business logic deserves the same lifecycle as application code. It should be reviewed, tested, deployed, and rolled back through the same engineering workflow.

None of this requires inventing a new architectural pattern. It's simply event driven state computation applied to a problem that has traditionally been solved with dashboards.

Where I landed

I spent years working in Customer Success before moving closer to engineering. One contrast became impossible to ignore.

Application logic lived in Git repositories, pull requests, and CI pipelines.

Customer logic lived in spreadsheets, drag and drop builders, and undocumented processes.

Infrastructure evolved toward deterministic systems.

Customer operations evolved toward dashboards.

That observation led me to build Kite.

Kite ingests events from existing systems and continuously computes customer state from rules written 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 feels closer to shipping infrastructure than configuring a dashboard.

kite init
kite validate
kite deploy

The engine is deterministic. If a customer isn't activated, it doesn't estimate why. It reports exactly which conditions were satisfied, which were missing, and which expected events never arrived.

AI has a limited role. It helps explain missing instrumentation and surface patterns. It never invents evidence or becomes the source of truth.

Whether Kite is the right implementation is almost beside the point. The architectural idea is what interests me most. Customer state feels like something that should be computed continuously instead of reconstructed every time someone opens a dashboard.

A takeaway you can use today

You don't need a runtime to start thinking this way.

Start by defining your customer states explicitly.

Most organizations don't actually have a formal definition of concepts like Healthy Customer, Activated Customer, or At Risk Customer. They have shared intuition.

If three people on your team define activation differently, then activation isn't a definition. It's an opinion.

Write your customer states as deterministic conditions.

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

You can still evaluate that definition manually if necessary. The important change is that you've transformed an implicit idea into explicit business logic.

Once the definition exists, automation becomes an implementation detail instead of a design problem.

Infrastructure stopped querying server health years ago. We defined the rules once and let systems compute the answers continuously.

I think customer state deserves the same treatment.