Making the Contract the Source of Truth
Made the CRM the single source of truth for customer access, designed to cut package launches from quarters to hours.
Overview
Defined and led the build of the layer that decides what every customer is allowed to use, replacing a fragmented patchwork of feature flags, database columns, and manual overrides with a single contract-driven source of truth.
Problem
Feature access was managed across five-plus disconnected systems: feature flags, database columns, a contract-term table, environment variables, frontend logic, and manual overrides in an internal support tool. No one place could answer what a customer was actually entitled to. Every packaging change required engineering to wire access rules by hand across all of those systems, so launching a new package took roughly a full quarter, and a backend team was spending a large share of its time on 'why can't I access this feature?' support tickets.
Constraints
- Zero customer impact was non-negotiable: the new path had to match the old one exactly before any cutover.
- The CRM could only become the source of truth after classifying and remediating tens of thousands of accounts whose access had drifted from their contracts.
- Multiple go-to-market motions (SMB, federal, regional packages) were blocked in the pipeline waiting on packaging infrastructure.
- The rollout needed a fast rollback path if anything diverged in production.
Approach
Partnered with product and the key engineering architects to make the CRM the single authority on customer access, then led the team through architecture, implementation, and a phased dark launch. Contract data flows from the CRM through the data pipeline into an entitlements model that drives feature-flag context, so what a customer bought is what the product delivers, automatically. Every stage ran in parallel against the existing system and had to reach full parity before taking real traffic.
Key Decisions
Make the CRM the single source of truth for entitlements, rather than improving the existing patchwork
The core problem was that no system could authoritatively say what a customer should have. Anchoring entitlements to the contract record in the CRM meant sales, support, finance, and product could all read one place, and packaging changes stopped requiring engineering to reconcile five systems by hand.
- Keep feature flags and database columns as the source of truth and add tooling to keep them in sync.
- Build a standalone entitlements database disconnected from the contract system.
Run the new system in parallel to full parity before cutover, gated by an environment-variable kill switch
Any divergence between what a customer paid for and what they could access was a trust and revenue problem. Requiring 100% parity in a parallel run, behind a two-way-door toggle, made the cutover reversible and provably safe.
- Hard cutover once the system passed internal testing.
Hand package creation to revenue operations, with no engineering in the loop
A faster engineering process would have shortened the bottleneck; removing engineering from the path entirely eliminated it. Once entitlements were contract-driven, non-engineers could define and launch packages directly.
- Keep engineering as the gatekeeper but streamline the internal request-and-build process.
Tech Stack
- Salesforce
- Unleash
- PostgreSQL
- GraphQL
- Redshift
- Python
Result & Impact
- projected 90+ days to under 5 business daysNew package launch time
- ~$200K/year projected (roughly 1 FTE)Engineering capacity reclaimed
- one CRM record any team can read for exact customer accessSource of truth
- SMB, federal, and regional packagesUnblocked go-to-market
The platform reached its first production launch phase near the end of my tenure, with the projected outcomes on a clear trajectory rather than fully realized. What was delivered was the harder-to-see part: a single contract-driven model that any part of the company can read to know exactly what a customer experiences, and a packaging path that no longer routes through engineering.
Learnings
- The expensive problem wasn't the feature flags; it was having no authoritative answer to 'what should this customer have?' Fixing the source of truth mattered more than any individual system.
- A contract-to-product path is only trustworthy if you prove parity before cutover; a reversible, parallel-run rollout bought the confidence to launch.
- Removing engineering from the packaging path entirely, rather than speeding it up, was what actually killed the bottleneck.
The Patchwork
Deciding what a customer could use meant reading five or more systems that didn’t agree with each other: feature flags, columns on an account table, a contract-term table, environment variables, frontend logic, and one-off overrides set by hand in an internal support tool. Handshake deals and temporary grants lived nowhere durable. When a temporary override expired, features would quietly appear or disappear, and a support ticket would follow. No single team, not sales, not support, not finance, not product, had a reliable place to check what a customer should have.
One Source of Truth
The design decision that mattered most was to stop treating any of those systems as authoritative and make the contract record in the CRM the single source of truth. Contract data flows from the CRM through the data pipeline into an entitlements model, which builds the feature-flag context the product reads. A change to a customer’s contract propagates to what they see in the product within minutes, with no engineer in the path. Package definitions moved out of code and into something revenue operations could edit directly.
Launching Without Breaking Anything
Because the system governs exactly what every paying customer can access, there was no acceptable margin for divergence. The new path ran in parallel with the old one and had to reach full parity across tens of thousands of accounts before it took real traffic, with a single environment-variable toggle to fall back instantly. Getting there also meant a cross-functional data-hygiene effort to classify and remediate accounts whose access had drifted from their contracts over the years, so the CRM could credibly become the authority.
Where It Landed
By the end of my tenure the platform had reached its first production launch phase, with the headline outcomes, sub-5-day package launches and roughly a full engineering role’s worth of capacity returned, projected and on track rather than fully banked. The realized win was structural: the company gained one contract-driven answer to what each customer is entitled to, and a packaging path that no longer depends on engineering.