Decision Enginers in A Post SaaS world

Decision Engines in the Post-SaaS Age of Coding Agents#

An example toy model for decision engines#

Imagine a theme park fountain with four valves:

Valve A increases water height.
Valve B makes mist that cools visitors.
Valve C powers pumps that also draw electricity at peak prices.
Valve D attracts more foot traffic to adjacent shops (because humans like shiny arcs of water. Proven fact).

Your goal each hour: pick valve positions to maximize

\[ profit = shop margin + ticket upsell − electricity − maintenance \]

subject to:

Weather (affects cooling value)
Grid prices (affect pump cost)
Wear rates (affect failures)
Visitor flows (affect revenue)

Three components matter:

Prediction: forecast weather, traffic, prices, wear.
Causality: understand how each valve actually influences outcomes (not just correlates).
Optimization: choose the valve positions that maximize profit under uncertainty and constraints.

Now swap "valves" for: - ad spend - maintenance intervals - staffing levels - power dispatch or - portfolio weights.

Different verticals, same engine.

What we're building#

Causify is horizontal but not SaaS. We are building the decision engine layer for enterprises operating under uncertainty, not another SaaS workflow tool.

We focus on regime-sensitive, high-stakes, probabilistic decision problems. The kind where wrong calls cost real money. And where AI agents alone, unguided by causal structure and economic objectives, cannot be trusted.

"Aren't you in too many markets?"

When we pitch to customers or (obsolete VCs), we sometimes hear: "Hedge funds, wind turbines, school inventory, power curtailment... that's too many markets." Fair. Venture loves focus. But this misses the core: we're in one market: automating decisions.

Consider the parallels:

Hedge funds estimate alpha and risk from price histories, disclosures, and macro data, and then optimize portfolios.
Wind operators predict component failures from sensor data and physics, and then schedule maintenance.
Supply chains forecast Chromebook parts from seasonality and breakage, and then set reorder policies.
Utilities forecast curtailment from market prices, demand, and grid data, and then dispatch and hedge.

Notice the common structure:

Predict Y based on an understanding of how system Z works, using data X, and then make an optimal decision based on Y.

The unifying stack

Prediction: robust ML for Y on X.
System dynamics: causal AI to encode how Z really works (counterfactuals and interventions).
Decision-making: optimization under uncertainty with explicit economics and constraints.

Our moat

Causal tooling: primitives for interventions, counterfactual queries, and regime shifts.
Decision optimization layer: cost-aware, constraint-aware control that sits on top of predictions.
Domain calibration: reusable causal components, tuned cross-sectionally across industries.
Complexity that's non-trivial to replicate: it's hard to bolt counterfactual optimization onto a dashboard.
Clear messaging for management: decisions explained in business terms, with levers and trade-offs made explicit.

How it looks in practice

Hedge fund
Predict: short-horizon returns, liquidity, and risk under multiple regimes.
Causality: stress-test exposures to policy shocks or supply interruptions.
Optimize: size positions to maximize expected utility with drawdown limits and transaction costs.
Wind operator
Predict: bearing failure probabilities from SCADA and weather.
Causality: how operating modes and loads affect degradation.
Optimize: maintenance scheduling to minimize expected downtime plus parts and labor.
K–12 device supply
Predict: breakage and seasonal need by school.
Causality: policy changes (new courses, funding cadence) on demand.
Optimize: reorder points and safety stocks under budget constraints.
Power utility
Predict: curtailment risk, node prices, and demand.
Causality: grid constraints, market rules, renewable intermittency.
Optimize: dispatch, hedging, and curtailment mitigation to hit profit and reliability targets.

From "app" to "engine"

Most SaaS apps package a median workflow. Engines encode how your world works and choose actions accordingly. Apps give you buttons. Engines give you levers, guardrails, and reasons.

What to ask your team this quarter

If Claude Code or Cursor can implement 80% of a horizontal tool in a day, which licenses should we retire first?
Which of our decisions are high-cost, high-uncertainty, and regime-sensitive, and therefore deserve an engine, not a report?
Where are we renting average outcomes when we could own tailored ones?
What would it take to express our economics (constraints, penalties, incentives) as code, and wire them to levers we control?

A brief note on "vibe coding"

There's a temptation to treat AI agents like a magical intern who never sleeps and always comments their code. Tempting, yes. Also: the magical intern will happily string together three incompatible SDKs and cheerfully pass all unit tests you forgot to write. Engineering discipline isn't optional; it's the multiplier. AI-native means agents plus process.

Why now, and what's next

Build-vs-buy flipped because Agent Hours got cheap and reliable, while control and data gravity got valuable.
Customization wins because outcomes, not features, determine value, and because every interesting problem lives in a long tail.
AI-native operating models compound because they align how you work with how agents work: modular, documented, and testable.

SaaS isn't "dead," exactly; it's just been repriced by a new labor market: code-generating agents plus a smaller, sharper human loop. In that world, the seat license looks strangely archaic, like paying rent on a calculator.

If you're running decisions under uncertainty and the cost of getting them wrong is non-trivial, you don't need another app. You need a decision engine.

We're building it. Bring us your valves.