Why your SaaS is making you dumber

Most large organizations do not have internal tooling. They have SaaS subscriptions.

The distinction matters more than it appears. A SaaS product solves a generalized version of your problem, the version common enough across enough customers to justify productization. It rarely solves the specific version shaped by your content models, team structure, editorial workflows, and the particular mix of legacy decisions and current constraints.

Over time, the gap between what the tool does and what the organization needs gets covered with workarounds. The workarounds become institutional knowledge. The institutional knowledge becomes dependency. The organization gradually loses the ability to understand or maintain the systems it relies on most.

Penn State had none of this tooling when I arrived. Not because the problems did not exist, schema drift across Contentful spaces, manual content migrations, no experimentation capability, broken redirects with no visibility, authoring interfaces cluttered with fields that applied only to certain layouts, but because the default response had been to buy a SaaS product or accept manual process. Building internal tooling requires believing your problems are specific enough to be solved specifically, and that belief is harder to reach than it sounds.

The suite I built was a direct response to that specificity. A model sync dashboard compared schemas across spaces and corrected drift in one action. A content export tool turned multi-hour engineering migrations into self-service editorial workflows. A redirect audit fetched rules from Edge Config, tested each one automatically, and surfaced broken chains before they became user-facing failures. A shared authentication layer gave every dashboard role-based access across multiple Contentful environments without exposing destructive actions to non-technical users.

Without custom access controls, accidental production-level model damage is not theoretical. It is exactly the kind of failure that eventually happens.

The conditional fields system taught me the most about the gap between how authors think and how engineers think.

The concept sounds simple: show or hide fields based on what an editor selects. Reduce authoring cognitive load by presenting only what is relevant in context. Authors always want this. At scale, with dozens of content types and hundreds of field combinations, the logic governing visibility becomes its own system, one that must be maintained, documented, and understood by engineers who did not create it.

The author's demand is less complexity. The engineer's demand is less complexity. They are aligned in direction and still in tension in implementation.

That balance did not come from planning. It came from iteration and direct observation of real usage. The final approach reduced junk fields, condensed content models, removed entire categories of documentation overhead, and improved content consistency in measurable ways. Getting there required being wrong more than once.

Internal tooling teaches something external product work often cannot. External products give you signals, analytics, support tickets, conversion metrics, but those are still distance signals. With internal tools, you watch someone use the system while sitting nearby. You see hesitation in real time. You see which fields they skip, which flows they abandon, and which interface regions they no longer trust. The pain points are largely unspoken and directly observable in a way no dashboard can replicate.

A system is only good when it meets people where they are. External products have to guess where that is. Internal tools do not have that excuse.