SPPM: the four-plague model for engineering outcomes

Raise SPPM. Stop paying the plague tax.

SPPM is a compact lens for what hurts software teams most: Security, Productivity, Performance, and Maintenance. FUDD’s web stack is built to improve all four at once: typed logic, explicit SQL, SSR UI, fast tooling, and measurable proofs.

SPPM in one sentence

tap pills above

Security: shrink the exploit surface

Less dynamic ambiguity, fewer injection paths, clearer boundaries, better tracing.

typed boundariespolicy at edgeexplicit SQLrequest tracing

See FUDD features Explore mapping

Design rule

SPPM rises when correctness is cheap and performance is predictable.

DX rule

If the safe way isn’t the fast way, teams won’t sustain it.

SPPM core (3D)

Tap nodes

Each pillar reveals which FUDD features improve it (and why).

SPPM radar

drag sliders below

Typing & proofs

Tooling & DX

Runtime efficiency

Observability

Radar is a toy model: swap with your real metrics (incidents, cycle time, p95, change failure rate).

What SPPM measures

SPPM is not a KPI—you can’t “game it” without reality pushing back. It’s a design constraint: when it improves, you tend to see fewer incidents, faster iteration, lower infra cost, and safer changes.

The plague tax

Security: exploit paths + incident recovery
Productivity: iteration latency + cognitive load
Performance: p95, throughput, infra spend
Maintenance: regression risk + brittle coupling

SPPM pain matrix

tap cells

Tap a cell

Each plague interacts with the others. SPPM improves when you remove root causes, not symptoms.

FUDD web features that raise SPPM

These are the engineering levers that move SPPM in web apps. The focus is not novelty—it’s compounding advantage.

Typed server logic (Haskell)

S • M

Make invalid states unrepresentable. Shrink ambiguity at boundaries.

SSR UI with functional components (Fuddle)

P • P

Deterministic render + controlled interactivity (HTMX over websocket).

Explicit SQL with compile-time checks (Hasql-TH)

S • P • M

Eliminate stringly-typed DB calls. Keep RDBMS power without ORM drift.

Feature → SPPM mapping

hover nodes

Hover a node

See how engineering features affect each SPPM pillar.

Tooling: Wapp + Daniell

Conventions, scaffolding, hot reload, and project traversal reduce iteration friction.

Templating: Cannelle

AST-based parsing + compiled templates reduce runtime cost and confusion.

A concrete example (typed SQL)

-- Illustrative: compile-time validated SQL (shape + bindings)
-- (Replace with your Hasql-TH conventions)
{-
selectUserById :: UUID -> Session (Maybe User)
selectUserById uid = statement uid [singletonStatement|
  select id, email, created_at
  from app_user
  where id = $1::uuid
|]
-}

-- Result: fewer runtime surprises, faster refactors, clearer DB boundaries.

This snippet is illustrative; wire to your actual schema + statement templates.

Build your SPPM loadout

Pick the engineering features you want to emphasize. The score is a toy—use it to reason about trade-offs.

Loadout toggles

Typed boundaries everywhere

Errors move left: compile-time and tests, not production.

Explicit SQL (no ORM drift)

Performance + correctness by making DB operations explicit and checked.

SSR UI + HTMX event routing

Fast perceived speed, fewer client-side failure modes.

Tracing + introspection

Find bottlenecks and suspicious patterns quickly; reduce MTTR.

Wapp structure + scaffolding (Daniell)

Reduce cognitive load: conventions, project traversal, hot reload, CI hints.

Compiled templates (Cannelle)

AST-aware parsing and fast rendering reduce runtime overhead and mistakes.

Loadout output

Your loadout currently emphasizes balanced SPPM.

SPPM scorecard

auto-updates

Scorecard is a reasoning tool. Replace with your organization’s SLOs and incident stats.

Want the real numbers?

Run a baseline → apply one lever → measure

SPPM improves when you prove changes in staging and ship with rollback.

How to prove SPPM gains (without vibes)

A framework is only as good as the evidence you can generate during change. FUDD’s philosophy: ship with rollback, add tracing early, and measure before/after.

Security proof

Threat model + boundary checks + request normalization + rate limits + audit logs.

Productivity proof

Cycle time, reviewer load, hot-reload latency, defect escape rate.

Performance proof

p95 latency, throughput, infra cost per request, cache hit ratio, DB time share.

Maintenance proof

Change failure rate, regression rate, time-to-fix, refactor effort per feature.

Minimal SPPM audit checklist

# 0) Pick one route / page / flow
# 1) Add tracing: request_id, route, handler, php_time, db_time, payload_size
# 2) Add guardrails: normalize params, rate-limit auth endpoints, block legacy attack surfaces
# 3) Baseline: p50/p95, RPS, cache hit, incident count, mean time to recover
# 4) Apply one lever: SSR template OR typed handler OR query rewrite
# 5) Compare: same load, same traffic mix
# 6) Ship with rollback + alerts
# 7) Repeat with next highest ROI surface

Wire these checks into your CI/CD and make SPPM improvement a normal dev habit.