Engineering rigor: How we eliminate plan-feature drift in growing SaaS codebases

Why this post exists

This is an operator-side transparency post, not a sales pitch. We want EU mid-market buyers — CTOs, Heads of Engineering, compliance reviewers — to see how we run our codebase, because that's a reasonable signal of how we'll handle their data.

Specifically: when a SaaS product has multiple pricing tiers and many feature flags, plan-feature drift is a real bug class that can affect what customers see and pay for. We close it mechanically. Here's how at a high level.

The problem: scattered plan-tier checks drift over time

Most growing SaaS codebases accumulate plan-tier checks in many places — pricing-gate render paths, billing UI, recommendation scoring, scheduled email jobs. Each check encodes the same intent: "does this customer's tier include capability X?".

A typical pattern looks like a hardcoded list of tier names compared against the user's tier. It's correct on the day it's written. Months later, a new tier is added. The new tier should also unlock the capability — but the engineer who adds the tier doesn't know how many parallel checks exist, scattered across components written by different people at different times.

One check gets updated. Several don't. The customer on the new tier:

• Sees the capability on some pages
• Doesn't see it on others
• Gets a downgraded scheduled email because the cron job's eligibility check wasn't updated

This is silent. No exception is thrown. No log line fires. The customer just experiences inconsistent behavior — sometimes paying for a capability they can't fully use.

We audited and consolidated every such gate behind a single derivation function during routine cleanup work. The automated check described below ensures it stays consolidated as new capabilities are added.

The solution: server-derived capability flags

Pricing logic lives in one canonical configuration file — a single source of truth where each tier declares which capabilities it includes. The shape, abstracted:

midTier: {
  features: {
    advancedReports: true,
    integrations: true,
    // each capability declared once, here
  },
}

Our authenticated user endpoint derives boolean capability flags from that registry, and every consuming surface reads the derived flag instead of doing its own tier comparison. Add a new tier? Update one file. The flag propagates everywhere automatically.

Mechanical defense: automated commit-time check

A single source of truth helps only if engineers actually use it. So we run an automated check at commit time that ensures the canonical pattern is used. When the check finds a non-canonical reference, it surfaces actionable feedback to the engineer with the file and line where the issue is.

The check is idempotent and fast. It runs alongside our other commit-time invariants and stays out of the way until something is genuinely off.

Customer benefit: correct access, no surprise gates

The visible result for our customers:

• Correct capability access: every paying customer sees exactly the capabilities their tier includes — not fewer, not more.
• Consistent billing posture: centralized derivation prevents one part of the system from including a tier in a metered job that another part excludes.
• Predictable downgrades: our standard grace period after a downgrade applies uniformly across every capability, because the same effective-tier resolver drives every gate.

What this is part of

Our engineering process leans on closure checklists, plan-of-record documents, and a maintained registry of lessons learned. The plan-feature consistency work is one of many similar invariants we maintain mechanically — across legal documents, locale parity, accessibility wiring, and AI-surface disclosures, among others.

We publish this kind of post because EU B2B buyers in 2026 are right to ask "how do you actually run this?" before signing a Data Processing Agreement. The answer for us: deliberately, with mechanical defenses, and with a paper trail of decisions.

If you're evaluating HumanKey for your traffic intelligence stack, our Data Processing Agreement, Privacy Impact Assessment, Sub-Processor list, and DORA self-assessment are all public. Start with whichever your compliance team needs first.

For a free trial, no credit card required, the snippet takes under two minutes to install.