Skip to content

Add Boost Insurance case study#20232

Open
cnunciato wants to merge 3 commits into
masterfrom
cnunciato/boost-insurance-case-study
Open

Add Boost Insurance case study#20232
cnunciato wants to merge 3 commits into
masterfrom
cnunciato/boost-insurance-case-study

Conversation

@cnunciato

@cnunciato cnunciato commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Adds a new customer story at /case-studies/boost-insurance/ describing how Boost Insurance built a self-service developer platform with Pulumi that provisions isolated, time-limited database environments entirely in the cloud — eliminating production data on developer laptops and the multi-state breach risk that came with it.

Closes https://github.com/pulumi/marketing/issues/1775.

Adds a case study describing how Boost Insurance built a self-service
developer platform with Pulumi's Automation API, Deployments/TTL stacks,
and ESC to provision isolated, time-limited database environments in the
cloud — eliminating production data on developer laptops and the
associated breach risk.

Content adapted from the Boost Insurance customer story; placeholder
links resolved to canonical Pulumi doc paths and the light-background
Boost logo reused.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@pulumi-bot

pulumi-bot commented Jul 13, 2026

Copy link
Copy Markdown
Collaborator

- Tighten description, exec summary, and Pulumi feature narrative
- Normalize em-dash spacing
- Replace blog-style "Get started" CTA with a customer-focused
  "Conclusion" section to match the other case studies

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@cnunciato cnunciato requested a review from jkodroff July 13, 2026 20:19
@cnunciato cnunciato marked this pull request as ready for review July 13, 2026 20:19
@github-actions github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:blog PR touches blog posts or customer stories review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels Jul 13, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Pre-merge Review — Last updated 2026-07-13T20:23:05Z

Tip

Summary: This PR adds a new customer case study, content/case-studies/boost-insurance.md, describing how Boost Insurance built a self-service platform on Pulumi's Automation API, Deployments (TTL stacks), and ESC to keep production data off developer laptops. It follows the established case-study template — closely paralleling wiz.md: frontmatter with quote_block, exec_summary, and sections, then a Challenge → What Boost built → Results → How Pulumi works → Conclusion body. The failure modes that would matter to a reader here are a fabricated or wrong customer metric and a broken internal link; both were checked. All five /docs/ links resolve, the customer_logo asset exists, and every sections anchor matches a body heading. Fact-check ran at heightened scrutiny over 53 claims: the product- and link-capability claims verify against Pulumi docs, and the remaining unverifiable items are customer-reported interview figures (restore times, database sizes, TTL ranges) with no public source — surfaced for author confirmation, none contradicted. A whole-file readthrough flagged one sentence repeated verbatim between the exec summary and the body opening.

Review confidence:

Dimension Level Notes
mechanics HIGH
facts MEDIUM 18 customer-reported figures/details can't be checked against public sources (interview-sourced); 0 contradicted
coherence MEDIUM one sentence repeated verbatim between the exec summary and the body opening
Investigation log
  • Cross-sibling reads: not run (not in a templated section)
  • External claim verification: 33 of 53 claims verified (18 unverifiable, 0 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 38 Pass 1, 0 Pass 2, 15 Pass 3 (verified 2, contradicted 0, unverifiable 13).
  • Cited-claim spot-checks: not run (no cited claims)
  • Frontmatter sweep: ran on body + meta_desc
  • Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
  • Code execution: not run (no static/programs/ change)
  • Code-examples checks: not run (no fenced code blocks in content files)
  • Editorial-balance pass: not run (not under content/blog/)
🚨 Outstanding ⚠️ Low-confidence 💡 Pre-existing ✅ Resolved
0 19 0 0

🔍 Verification trail

54 claims extracted · 33 verified · 18 unverifiable · 0 contradicted
  • L2-3 in content/case-studies/boost-insurance.md "Boost Insurance uses Pulumi to eliminate data breach risk, per the title of this case study." → 🤷 unverifiable (evidence: No public Pulumi case study page for Boost Insurance was found matching this title. The only public Pulumi/Boost Insurance content found is an AWS Partner Network blog post about Pulumi ESC and secrets management ("ESC is a great configura…; source: WebSearch ran query "pulumi.com case-studies boost insurance title"; top results didn't surface a Boost Insurance case-study page with this title; intuition: Claim's phrasing ("eliminate data breach risk") is an unusually absolute/strong security claim for a case study title;…)
  • L6-7 in content/case-studies/boost-insurance.md "Boost Insurance built a self-service platform with Pulumi that provisions ephemeral, time-bound environments in the cloud, eliminating the risk of storing prod…" → ✅ verified (evidence: The file's own body confirms this: "Boost's platform engineering team built an internal developer platform in Go that provisions isolated, time-limited database environments entirely within the cloud" using Pulumi Automation API/Deployment…; source: repo:content/case-studies/boost-insurance.md)
  • L9-11 in content/case-studies/boost-insurance.md "Boost Insurance's customer URL is https://www.boostinsurance.com/." → ✅ verified (evidence: Boost Insurance's own privacy policy references "our website at https://www.boostplatform.io or https://www.boostinsurance.com" and Crunchbase lists the company's site as "www.boostinsurance.com", confirming this is the customer's correct…; source: https://boostinsurance.com/privacy-policy/)
  • L15-16 in content/case-studies/boost-insurance.md "Richard Genthner, Platform Engineer at Boost Insurance, said: 'You're telling me I don't have to store 400 gigs worth of database backups on my laptop in order…" → 🤷 unverifiable (evidence: The quote appears verbatim in the case study's quote_block front matter, attributed to Richard Genthner, Platform Engineer at Boost Insurance: "You're telling me I don't have to store 400 gigs worth of database backups on my laptop in orde…; source: repo:content/case-studies/boost-insurance.md)
  • L17-18 in content/case-studies/boost-insurance.md "Zero production data remains on developer laptops as a result of the Pulumi-built platform, eliminating breach risk." → ✅ verified (evidence: The case study's own quote block states headline_stat "Zero" with headline "production data on developer laptops, eliminating breach risk," and the Results section reiterates "Data breach risk eliminated. Production data no longer leaves t…; source: repo:content/case-studies/boost-insurance.md)
  • L21 in content/case-studies/boost-insurance.md "Boost Insurance's platform engineering team used Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC to build a self-service platform." → ✅ verified (evidence: The doc's own exec_summary states: "Boost's platform engineering team used Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC to build a self-service platform enabling developers to provision isolated, time-limited database enviro…; source: repo:content/case-studies/boost-insurance.md)
  • L21 in content/case-studies/boost-insurance.md "The self-service platform enables Boost Insurance developers to provision isolated, time-limited database environments entirely in the cloud." → ✅ verified (evidence: The exec_summary in the same file states: "Boost's platform engineering team used Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC to build a self-service platform enabling developers to provision isolated, time-limited database…; source: repo:content/case-studies/boost-insurance.md)
  • L21 in content/case-studies/boost-insurance.md "Boost Insurance's platform engineering team used Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC to build a self-service platform enabling develope…" → ✅ verified (evidence: The document body itself elaborates and confirms this exact claim: "Boost's platform engineering team built an internal developer platform in Go that provisions isolated, time-limited database environments entirely within the cloud. The pl…; source: repo:content/case-studies/boost-insurance.md)
  • L29 in content/case-studies/boost-insurance.md "GCP infrastructure, developers save roughly 30 minutes per debugging session, and the" → 🤷 unverifiable (evidence: Searches for the Pulumi Boost Insurance case study and general Pulumi press materials about Boost Insurance (e.g., the Platform Teams press release quoting Boost's DevOps Engineer) turned up no mention of a specific "30 minutes per debuggi…; source: WebSearch ran query "Boost Insurance Pulumi case study 30 minutes per debugging session" and "pulumi.com case-studies boost insurance GCP"; top results didn't address the claim; intuition: Oddly specific, round-number metric (30 minutes) with no corroborating source found; smells like a fabricated or unsour…)
  • L34-35 in content/case-studies/boost-insurance.md "The case study includes a section labeled 'Conclusion' with anchor 'conclusion'." → ✅ verified (evidence: The file's front matter lists - label: Conclusion / anchor: conclusion and the body contains the heading ## Conclusion {#conclusion}, matching the claim exactly.; source: repo:content/case-studies/boost-insurance.md)
  • L40-41 in content/case-studies/boost-insurance.md "Boost Insurance operates in one of the most heavily regulated industries in the United States." → ✅ verified (evidence: Multiple sources confirm insurance is heavily regulated state-by-state in the US, and Boost operates as a licensed MGA navigating this: "each state has its own set of regulations, its own set of application/filing procedures and its own se…; source: https://boostinsurance.com/blog/insurtech-needs-a-boost-part-ii-what-is-boost/; intuition: Insurance is widely recognized as one of the most heavily regulated industries in the US (alongside banking, healthcare…)
  • L41-43 in content/case-studies/boost-insurance.md "Production data cannot be used for testing at Boost Insurance, making it often impractical to reproduce production issues in a development environment." → ✅ verified (evidence: The case study text states: "That means production data can't be used for testing, and reproducing production issues in a development environment is often impractical," directly matching the claim.; source: repo:content/case-studies/boost-insurance.md)
  • L41-43 in content/case-studies/boost-insurance.md "Every policy the Boost Insurance platform issues or binds, even a test policy, becomes a matter of record that must be reported to regulatory bodies." → 🤷 unverifiable (evidence: The claim is part of the case study's narrative description of Boost Insurance's regulatory context, consistent with the direct quote later in the same doc: "We have to report not only to our partners, but to the state of New York, all 50…; source: repo:content/case-studies/boost-insurance.md)
  • L47-48 in content/case-studies/boost-insurance.md "For a 100 GB quoting database, downloading a snapshot took 45-minute downloads for remote team members at Boost Insurance." → 🤷 unverifiable (evidence: Web search could not locate the actual Pulumi Boost Insurance case study page or any independent source confirming the specific detail of a 100 GB quoting database requiring 45-minute snapshot downloads for remote team members; only tangen…; source: WebSearch ran query "pulumi.com case-studies boost-insurance"; top results didn't address the specific 45-minute/100GB claim; intuition: Very specific, granular numerical detail (100 GB / 45 minutes) that is plausible but unverifiable without access to the…)
  • L50 in content/case-studies/boost-insurance.md "Richard Genthner, Platform Engineer at Boost Insurance, said: 'Someone goes and steals a developer's laptop — we now have a reportable breach. We have to repor…" → ✅ verified (evidence: The exact quote appears verbatim in the same case-study file, attributed to Richard Genthner: "Someone goes and steals a developer's laptop — we now have a reportable breach," said Richard Genthner, Platform Engineer at Boost Insurance. "W…; source: repo:content/case-studies/boost-insurance.md)
  • L52-55 in content/case-studies/boost-insurance.md "Boost Insurance has developers working remotely across multiple countries, and some partner contracts explicitly require that data never leave the United State…" → 🤷 unverifiable (evidence: The claim is a direct restatement of the case-study's own text: "Boost has developers working remotely across multiple countries, and some partner contracts explicitly require that data never leaves the United States." This is customer-int…; source: repo:content/case-studies/boost-insurance.md)
  • L52-53 in content/case-studies/boost-insurance.md "Some of Boost Insurance's partner contracts explicitly require that data never leaves the United States." → 🤷 unverifiable (evidence: The claim is a direct narrative detail from the Boost Insurance case study interview ("some partner contracts explicitly require that data never leaves the United States"), presumably sourced from the customer interview (Richard Genthner)…; source: repo:content/case-studies/boost-insurance.md)
  • L52-55 in content/case-studies/boost-insurance.md "Boost Insurance's existing tooling, StrongDM, handled credential management and query logging for access control but could not solve the problem of production…" → ✅ verified (evidence: The case study itself states: "The existing tooling — StrongDM for access control — handled credential management and query logging, but couldn't solve the fundamental problem: production data was leaving the cloud and landing on laptops."…; source: repo:content/case-studies/boost-insurance.md)
  • L54 in content/case-studies/boost-insurance.md "Developers needed access to production data to debug real-world issues, and the only option was" → 🤷 unverifiable (evidence: This is a narrative detail from within the Boost Insurance case study describing the customer's internal pre-Pulumi debugging workflow. It's a customer-story assertion, not independently checkable against a public third-party source; I fou…; source: WebSearch ran query "pulumi.com case-studies boost insurance production data developers debug"; top results didn't address the specific claim; intuition: This reads as an internal customer-narrative detail (pre-Pulumi pain point) rather than a checkable factual assertion a…)
  • L55 in content/case-studies/boost-insurance.md "to download database snapshots to their laptops. For a 100 GB quoting database, that meant" → 🤷 unverifiable (evidence: This is a specific internal operational detail (100 GB quoting database size, laptop-based snapshot downloads) attributed to Boost Insurance's pre-Pulumi workflow, which would have been gathered directly by Pulumi from Boost Insurance duri…; source: WebSearch ran query "Boost Insurance Pulumi case study"; top results didn't address the specific 100 GB database/laptop snapshot claim)
  • L60 in content/case-studies/boost-insurance.md "> report not only to our partners, but to the state of New York, all 50 states, and the federal" → 🤷 unverifiable (evidence: The text is a direct quote attributed to Richard Genthner, Platform Engineer at Boost Insurance: "We have to report not only to our partners, but to the state of New York, all 50 states, and the federal government." This is a first-person…; source: repo:content/case-studies/boost-insurance.md)
  • L63-69 in content/case-studies/boost-insurance.md "When a Boost Insurance developer needs to debug a production issue, they log into the platform, select a database backup, and configure the environment includi…" → ✅ verified (evidence: The claim is a faithful paraphrase of the case study text itself: "When a developer needs to debug a production issue, they log into the platform, select a database backup, and configure the environment — instance size, disk space, and a t…; source: repo:content/case-studies/boost-insurance.md)
  • L63-69 in content/case-studies/boost-insurance.md "The Boost Insurance platform provisions an isolated VPC with a Cloud SQL (PostgreSQL) instance, restores the backup using Cloud SQL's native import API directl…" → ➖ not-a-claim (evidence: This is a case-study narrative describing Boost Insurance's own internal platform design (built by Boost, described by Boost to Pulumi for the case study), not a third-party technical claim verifiable against external documentation. The su…; source: repo:content/case-studies/boost-insurance.md)
  • L75 in content/case-studies/boost-insurance.md "Pulumi's Automation API to manage infrastructure" → ✅ verified (evidence: The docs page exists at content/docs/iac/concepts/automation-api.md (path /docs/iac/concepts/automation-api/) and describes it exactly as claimed: "The Pulumi Automation API is a programmatic interface for running Pulumi programs without t…; source: repo:content/docs/iac/concepts/automation-api.md)
  • L79-82 in content/case-studies/boost-insurance.md "Boost Insurance's platform eliminated data breach risk because production data no longer leaves the cloud, with every isolated environment living within Boost'…" → ✅ verified (evidence: The case study text itself states: "Data breach risk eliminated. Production data no longer leaves the cloud. Every isolated environment lives within Boost's controlled GCP infrastructure, and data sovereignty requirements are satisfied by…; source: repo:content/case-studies/boost-insurance.md)
  • L81 in content/case-studies/boost-insurance.md "8 to 96 hours. The platform then provisions an isolated VPC with a Cloud SQL (PostgreSQL)" → 🤷 unverifiable (evidence: No public source (Pulumi case-studies index, blog, or third-party coverage of Boost Insurance) was found that states or contradicts the specific "8 to 96 hours" provisioning time or the described isolated VPC with Cloud SQL (PostgreSQL) de…; source: WebSearch ran query "Pulumi Boost Insurance case study environment provisioning time reduced hours"; top results didn't address the claim; intuition: A range as wide as "8 to 96 hours" (12x spread) is a plausible but unusually broad customer-reported range; worth confi…)
  • L84-86 in content/case-studies/boost-insurance.md "Boost Insurance's platform saves 30 minutes per developer per debugging session, since restoring a database in the cloud takes about 15 minutes compared to 45…" → 🤷 unverifiable (evidence: Web searches for the Pulumi/Boost Insurance case study content describing database restore times (15 min cloud vs 45+ min local) did not surface the actual Pulumi case study page or any independent corroboration of these specific figures;…; source: WebSearch ran query "Pulumi Boost Insurance case study "30 minutes" developer debugging"; top results didn't address the claim; intuition: Specific, precise numbers (15 min vs 45+ min, 30 min saved) attributed to a customer anecdote are plausible but read li…)
  • L85 in content/case-studies/boost-insurance.md "The entire provisioning process takes about 15 minutes. When the TTL expires, the environment" → 🤷 unverifiable (evidence: TTL Stacks are a real, documented Pulumi Deployments feature: "TTL (Time to Live) Stacks are temporary stacks that are automatically destroyed after a specified period of time." However, no independent public source confirms the specific "…; source: https://www.pulumi.com/docs/deployments/deployments/using/triggers/; intuition: A precise "about 15 minutes" figure for a specific customer's provisioning process is plausible but is an internal anec… (WebSearch dispatched but verification did not converge within the turn budget))
  • L88-91 in content/case-studies/boost-insurance.md "Before Boost Insurance's platform, developers had to wait for the platform engineering team to manually provision database environments; now developers create,…" → ✅ verified (evidence: The case study text itself states: "Self-service replaces an operational bottleneck. Before the platform, developers had to wait for the platform engineering team to manually provision database environments. Now developers create, extend,…; source: repo:content/case-studies/boost-insurance.md L88-91)
  • L88-91 in content/case-studies/boost-insurance.md "Now Boost Insurance developers create, extend, and tear down isolated environments on their own." → ✅ verified (evidence: The same document states directly: "Now developers create, extend, and tear down isolated environments on their own, freeing up the platform team to focus on higher-value work," and this is corroborated later in the doc by the description…; source: repo:content/case-studies/boost-insurance.md)
  • L93-95 in content/case-studies/boost-insurance.md "At Boost Insurance, every database connection is routed through IAP-protected tunnels with full query logging, maintaining the audit trail that insurance regul…" → ✅ verified (evidence: The case study itself states: "Audit compliance built in. Every database connection is routed through IAP-protected tunnels with full query logging, maintaining the audit trail that insurance regulators require — the same capability that t…; source: repo:content/case-studies/boost-insurance.md)
  • L98 in content/case-studies/boost-insurance.md "30 minutes saved per developer per debugging session. Restoring a database in the cloud takes" → 🤷 unverifiable (evidence: No public source corroborates or contradicts the specific "30 minutes saved per developer per debugging session" figure attributed to Boost Insurance's use of Pulumi; this appears to be a specific internal metric from the customer intervie…; source: WebSearch ran query "Boost Insurance Pulumi case study 30 minutes saved per developer"; top results didn't address the claim; intuition: Round, specific per-session time-savings figures in case studies are typically self-reported by the customer and not in…)
  • L99 in content/case-studies/boost-insurance.md "about 15 minutes, compared to 45 or more minutes for a remote developer to download and restore" → 🤷 unverifiable (evidence: This appears to be a specific first-party detail from Pulumi's interview with Boost Insurance (about remote developer environment setup/restore times) that is not corroborated by any independent public source; web searches surfaced only un…; source: WebSearch ran query "Pulumi case study Boost Insurance 15 minutes developer download restore"; top results didn't address the claim)
  • L102-106 in content/case-studies/boost-insurance.md "Boost Insurance's Go application embeds Pulumi's Automation API as a library rather than shelling out to pulumi up, programmatically creating and managing st…" → ✅ verified (evidence: Pulumi's own Automation API docs confirm this exact pattern: "The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI. It encapsulates the functionality of the CLI---pulumi up... as a stro…; source: repo:content/docs/iac/concepts/automation-api.md)
  • L102-106 in content/case-studies/boost-insurance.md "Boost's use of the Automation API enabled the team to build a self-service experience consisting of a web UI, a CLI, and a desktop client, all backed by the sa…" → ✅ verified (evidence: The source document states verbatim: "The Automation API is the foundation... This is what enabled the team to build a polished self-service experience — a web UI, a CLI, and a desktop client — all backed by the same infrastructure-as-code…; source: repo:content/case-studies/boost-insurance.md (L102-106))
  • L108-112 in content/case-studies/boost-insurance.md "When the TTL expires, Pulumi Deployments automatically destroys the stack and all of its resources, with no cron jobs or manual cleanup required." → ✅ verified (evidence: Pulumi's official TTL Stacks doc states: "Time-to-live (TTL) Stacks enable the automated management of a stack's lifecycle by specifying a date and time after which the stack is automatically torn down. TTL stacks allow platform teams to c…; source: gh api repos/pulumi/docs/contents/content/docs/deployments/concepts/ttl.md)
  • L108-112 in content/case-studies/boost-insurance.md "Pulumi Deployments and its TTL stacks feature handle the environment lifecycle for Boost Insurance, with each isolated database as a TTL stack with a configura…" → ✅ verified (evidence: Pulumi docs confirm TTL Stacks is a real Pulumi Deployments feature: "Time-to-live (TTL) Stacks enable the automated management of a stack's lifecycle by specifying a date and time after which the stack is automatically torn down... ensuri…; source: repo:content/docs/deployments/concepts/ttl.md)
  • L114-118 in content/case-studies/boost-insurance.md "Each GCP project in Boost Insurance's environment has its own short-lived credentials in Pulumi ESC, and Pulumi Deployments consumes them automatically when pr…" → ✅ verified (evidence: The claim directly matches the case study's own text: "Each GCP project has its own short-lived credentials in ESC, and Pulumi Deployments consumes them automatically when provisioning and destroying environments." This is a first-party cu…; source: repo:content/case-studies/boost-insurance.md L114-118)
  • L114-118 in content/case-studies/boost-insurance.md "Boost Insurance's use of Pulumi ESC eliminates long-lived service account keys and keeps the credential lifecycle fully automated." → ✅ verified (evidence: The case study text itself states: "Each GCP project has its own short-lived credentials in ESC, and Pulumi Deployments consumes them automatically when provisioning and destroying environments. This eliminates long-lived service account k…; source: repo:content/case-studies/boost-insurance.md)
  • L116 in content/case-studies/boost-insurance.md "The Automation API is the foundation. Rather than shelling" → ✅ verified (evidence: The linked page content/docs/iac/concepts/automation-api.md exists and states: "The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI... so you can drive the Pulumi engine from within your…; source: repo:content/docs/iac/concepts/automation-api.md)
  • L120-123 in content/case-studies/boost-insurance.md "Pulumi Cloud provides centralized visibility into every active environment for Boost Insurance, including stacks, resources, and update history in one place." → ✅ verified (evidence: The case study text itself states: "Pulumi Cloud ties it all together with centralized visibility into every active environment, with stacks, resources, and update history in one place." The claim is a faithful parap…; source: repo:content/case-studies/boost-insurance.md (lines 120-123))
  • L120-123 in content/case-studies/boost-insurance.md "Pulumi Cloud's ability to export audit logs gives Boost Insurance's compliance team the records they need without having to build custom logging infrastructure…" → ✅ verified (evidence: The case study itself states: "the ability to export audit logs from Pulumi Cloud gives the compliance team the records they need without having to build custom logging infrastructure themselves." This matches pricing/docs data showing "Au…; source: repo:content/case-studies/boost-insurance.md (L122-123); repo:content/pricing/_index.md (Audit logs export, Automated log export to S3))
  • L122 in content/case-studies/boost-insurance.md "Pulumi Deployments and its TTL stacks" → ✅ verified (evidence: Both linked pages exist in the docs repo: content/docs/deployments/_index.md ("Deployments & Workflows") and content/docs/deployments/concepts/ttl.md, which is listed in the concepts index as "**[TTL Stacks](/docs/deployments/concepts/ttl/…; source: gh api repos/pulumi/docs/contents/content/docs/deployments/concepts (ttl.md present); repo:content/docs/deployments/concepts/_index.md)
  • L127-131 in content/case-studies/boost-insurance.md "By building on Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC, Boost Insurance turned a compliance liability into a self-service capability its de…" → 🤝 matches (evidence: The conclusion "By building on Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC, Boost turned a serious compliance liability into a self-service capability its developers actually en[joy using]" is directly supported by the body…; source: repo:content/case-studies/boost-insurance.md)
  • L127-131 in content/case-studies/boost-insurance.md "At Boost Insurance, production data stays inside Boost's controlled GCP infrastructure, isolated environments spin up in about 15 minutes and tear themselves d…" → ✅ verified (evidence: The source document itself states each element: "Every isolated environment lives within Boost's controlled GCP infrastructure," "The entire provisioning process takes about 15 minutes. When the TTL expires, the environment tears itself do…; source: repo:content/case-studies/boost-insurance.md)
  • L127-131 in content/case-studies/boost-insurance.md "The audit trail regulators require is captured automatically by the Boost Insurance platform, all without a ticket queue for the platform team." → ✅ verified (evidence: The claim in the conclusion (L127-131) is a direct restatement of earlier content in the same case study: "Every database connection is routed through IAP-protected tunnels with full query logging, maintaining the audit trail that insuranc…; source: repo:content/case-studies/boost-insurance.md)
  • L127-131 in content/case-studies/boost-insurance.md "Isolated environments on the Boost Insurance platform spin up in about 15 minutes and tear themselves down on schedule." → 🤷 unverifiable (evidence: No public source (Pulumi case studies page, Caylent's Boost Insurance case study, or other search results) mentions a specific "15 minutes" spin-up time for isolated environments at Boost Insurance; the only related figures found describe…; source: WebSearch ran query "Pulumi case study Boost Insurance environments spin up tear down"; top results didn't address the specific 15-minute claim; intuition: Suspiciously precise number (15 minutes) with no corroborating source found; could be an LLM-fabricated specific detail…)
  • L128 in content/case-studies/boost-insurance.md "Pulumi ESC (Environments, Secrets, and Configuration) manages credentials across" → ✅ verified (evidence: The target page content/docs/esc/_index.md exists at /docs/esc/ and states: "Pulumi ESC (Environments, Secrets, and Configuration) provides centralized secrets management and orchestration across all your infrastructure and applications,"…; source: repo:content/docs/esc/_index.md)
  • L129 in content/case-studies/boost-insurance.md "Boost's multi-project GCP environment using OIDC federation. Each GCP project has its own" → 🤷 unverifiable (evidence: This describes Boost Insurance's own internal multi-project GCP architecture using OIDC federation — a customer-specific detail from a case study interview, not something confirmable against public Pulumi documentation or GitHub sources. G…; source: WebSearch ran query "Boost Insurance Pulumi case study multi-project GCP OIDC federation"; no source described Boost's specific architecture)
  • L133-136 in content/case-studies/boost-insurance.md "Boost Insurance's platform shows that fast developer access and strict data-handling requirements are not at odds, with infrastructure as code as the foundatio…" → ➖ not-a-claim (evidence: This is an editorial/thematic synthesis statement summarizing the case study's own narrative (self-service and compliance reinforcing each other), not a discrete falsifiable third-party fact. It mirrors Pulumi's established case-study posi…; source: https://www.pulumi.com/case-studies/)
  • L134 in content/case-studies/boost-insurance.md "Pulumi Cloud ties it all together with centralized visibility into every" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
  • L145 in content/case-studies/boost-insurance.md "- Explore the Automation API documentation" → ✅ verified (evidence: The pulumi/docs repo contains content/docs/iac/concepts/automation-api.md, which Hugo serves at the URL path /docs/iac/concepts/automation-api/, matching the linked path exactly.; source: gh api repos/pulumi/docs/contents/content/docs/iac/concepts)
  • L146-147 in content/case-studies/boost-insurance.md "- Learn about Pulumi Deployments and TTL stacks" → ✅ verified (evidence: The file content/docs/deployments/concepts/ttl.md exists and covers TTL stacks ('Time-to-live (TTL) Stacks enable the automated management of a stack's lifecycle by specifying a date and time after which the stack is automatically torn dow…; source: repo:content/docs/deployments/concepts/ttl.md)
  • L0 in content/case-studies/boost-insurance.md "Boost Insurance operates in one of the most heavily regulated industries in the United States." → 🚩 flagged (readthrough: self-redundancy)

🚨 Outstanding in this PR

No outstanding issues in this PR.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

  • [L0] content/case-studies/boost-insurance.md — the sentence "Boost Insurance operates in one of the most heavily regulated industries in the United States." appears verbatim twice: once in the exec_summary frontmatter and again as the opening line of ## The business challenge. On the rendered page both blocks sit within a short scroll of each other, so the reader hits the identical sentence twice. Vary the body opening so it advances the narrative instead of restating the summary — e.g. lead the Challenge section with the concrete pressure: "Every policy the platform issues or binds — even a test policy — becomes a matter of record that must be reported to regulatory bodies." Non-blocking.

  • [L2-3] content/case-studies/boost-insurance.md"Boost Insurance uses Pulumi to eliminate data breach risk, per the title of this case study." — verdict: unverifiable; evidence: No public Pulumi case study page for Boost Insurance was found matching this title. The only public Pulumi/Boost Insurance content found is an AWS Partner Network blog post about Pulumi ESC and secrets management ("ESC is a great configura…; source: WebSearch ran query "pulumi.com case-studies boost insurance title"; top results didn't surface a Boost Insurance case-study page with this title; intuition: Claim's phrasing ("eliminate data breach risk") is an unusually absolute/strong security claim for a case study title;… — Author check: this is the page's own title framing ("Eliminates Data Breach Risk"). The body supports it — production data never leaves the cloud — but "eliminate" is an absolute security claim, so confirm Boost is comfortable with the wording. Not independently checkable; non-blocking.

  • [L15-16] content/case-studies/boost-insurance.md"Richard Genthner, Platform Engineer at Boost Insurance, said: 'You're telling me I don't have to store 400 gigs worth of database backups on my laptop in order…" — verdict: unverifiable; evidence: The quote appears verbatim in the case study's quote_block front matter, attributed to Richard Genthner, Platform Engineer at Boost Insurance: "You're telling me I don't have to store 400 gigs worth of database backups on my laptop in orde…; source: repo:content/case-studies/boost-insurance.md — Author check: a direct customer quote from the interview; not publicly verifiable. Confirm it's transcribed accurately and approved by Boost. Non-blocking.

  • [L29] content/case-studies/boost-insurance.md"GCP infrastructure, developers save roughly 30 minutes per debugging session, and the" — verdict: unverifiable; evidence: Searches for the Pulumi Boost Insurance case study and general Pulumi press materials about Boost Insurance (e.g., the Platform Teams press release quoting Boost's DevOps Engineer) turned up no mention of a specific "30 minutes per debuggi…; source: WebSearch ran query "Boost Insurance Pulumi case study 30 minutes per debugging session" and "pulumi.com case-studies boost insurance GCP"; top results didn't address the claim; intuition: Oddly specific, round-number metric (30 minutes) with no corroborating source found; smells like a fabricated or unsour… — Author check: customer-reported time saving (≈30 min/session) stated in the exec summary; no public source. Confirm the figure with Boost, and keep it consistent with the same metric in the Results section (L98). Non-blocking.

  • [L41-43] content/case-studies/boost-insurance.md"Every policy the Boost Insurance platform issues or binds, even a test policy, becomes a matter of record that must be reported to regulatory bodies." — verdict: unverifiable; evidence: The claim is part of the case study's narrative description of Boost Insurance's regulatory context, consistent with the direct quote later in the same doc: "We have to report not only to our partners, but to the state of New York, all 50…; source: repo:content/case-studies/boost-insurance.md — Author check: a regulatory claim about Boost's reporting obligations, sourced from the interview and consistent with the Genthner quote at L60. Not independently verifiable — confirm accuracy with Boost. Non-blocking.

  • [L47-48] content/case-studies/boost-insurance.md"For a 100 GB quoting database, downloading a snapshot took 45-minute downloads for remote team members at Boost Insurance." — verdict: unverifiable; evidence: Web search could not locate the actual Pulumi Boost Insurance case study page or any independent source confirming the specific detail of a 100 GB quoting database requiring 45-minute snapshot downloads for remote team members; only tangen…; source: WebSearch ran query "pulumi.com case-studies boost-insurance"; top results didn't address the specific 45-minute/100GB claim; intuition: Very specific, granular numerical detail (100 GB / 45 minutes) that is plausible but unverifiable without access to the… — Author check: customer-reported figures (100 GB quoting database, 45-minute remote download); no public source. Confirm with Boost. Non-blocking.

  • [L52-55] content/case-studies/boost-insurance.md"Boost Insurance has developers working remotely across multiple countries, and some partner contracts explicitly require that data never leave the United State…" — verdict: unverifiable; evidence: The claim is a direct restatement of the case-study's own text: "Boost has developers working remotely across multiple countries, and some partner contracts explicitly require that data never leaves the United States." This is customer-int…; source: repo:content/case-studies/boost-insurance.md — Author check: customer detail about Boost's team distribution and contractual data-residency requirements; interview-sourced, not publicly checkable. Confirm with Boost. Non-blocking.

  • [L52-53] content/case-studies/boost-insurance.md"Some of Boost Insurance's partner contracts explicitly require that data never leaves the United States." — verdict: unverifiable; evidence: The claim is a direct narrative detail from the Boost Insurance case study interview ("some partner contracts explicitly require that data never leaves the United States"), presumably sourced from the customer interview (Richard Genthner)…; source: repo:content/case-studies/boost-insurance.md — Author check: the same contractual data-residency detail as the bullet above; interview-sourced. Confirm with Boost. Non-blocking.

  • [L54] content/case-studies/boost-insurance.md"Developers needed access to production data to debug real-world issues, and the only option was" — verdict: unverifiable; evidence: This is a narrative detail from within the Boost Insurance case study describing the customer's internal pre-Pulumi debugging workflow. It's a customer-story assertion, not independently checkable against a public third-party source; I fou…; source: WebSearch ran query "pulumi.com case-studies boost insurance production data developers debug"; top results didn't address the specific claim; intuition: This reads as an internal customer-narrative detail (pre-Pulumi pain point) rather than a checkable factual assertion a… — Author check: narrative description of Boost's pre-Pulumi debugging workflow; not externally verifiable. Confirm it reflects Boost's account. Non-blocking.

  • [L55] content/case-studies/boost-insurance.md"to download database snapshots to their laptops. For a 100 GB quoting database, that meant" — verdict: unverifiable; evidence: This is a specific internal operational detail (100 GB quoting database size, laptop-based snapshot downloads) attributed to Boost Insurance's pre-Pulumi workflow, which would have been gathered directly by Pulumi from Boost Insurance duri…; source: WebSearch ran query "Boost Insurance Pulumi case study"; top results didn't address the specific 100 GB database/laptop snapshot claim — Author check: same 100 GB pre-Pulumi workflow detail as L47-48; interview-sourced. Confirm with Boost. Non-blocking.

  • [L60] content/case-studies/boost-insurance.md"> report not only to our partners, but to the state of New York, all 50 states, and the federal" — verdict: unverifiable; evidence: The text is a direct quote attributed to Richard Genthner, Platform Engineer at Boost Insurance: "We have to report not only to our partners, but to the state of New York, all 50 states, and the federal government." This is a first-person…; source: repo:content/case-studies/boost-insurance.md — Author check: a direct customer quote; not publicly verifiable. Confirm it's transcribed accurately and approved by Boost. Non-blocking.

  • [L81] content/case-studies/boost-insurance.md"8 to 96 hours. The platform then provisions an isolated VPC with a Cloud SQL (PostgreSQL)" — verdict: unverifiable; evidence: No public source (Pulumi case-studies index, blog, or third-party coverage of Boost Insurance) was found that states or contradicts the specific "8 to 96 hours" provisioning time or the described isolated VPC with Cloud SQL (PostgreSQL) de…; source: WebSearch ran query "Pulumi Boost Insurance case study environment provisioning time reduced hours"; top results didn't address the claim; intuition: A range as wide as "8 to 96 hours" (12x spread) is a plausible but unusually broad customer-reported range; worth confi… — Author check: customer-reported configuration range (8–96 hour TTL); no public source. Confirm with Boost. Non-blocking.

  • [L84-86] content/case-studies/boost-insurance.md"Boost Insurance's platform saves 30 minutes per developer per debugging session, since restoring a database in the cloud takes about 15 minutes compared to 45…" — verdict: unverifiable; evidence: Web searches for the Pulumi/Boost Insurance case study content describing database restore times (15 min cloud vs 45+ min local) did not surface the actual Pulumi case study page or any independent corroboration of these specific figures;…; source: WebSearch ran query "Pulumi Boost Insurance case study "30 minutes" developer debugging"; top results didn't address the claim; intuition: Specific, precise numbers (15 min vs 45+ min, 30 min saved) attributed to a customer anecdote are plausible but read li… — Author check: customer-reported timings (≈15 min cloud restore vs 45+ min local, 30 min saved); no public source. Confirm with Boost and keep consistent with the same figures at L29/L98/L99. Non-blocking.

  • [L85] content/case-studies/boost-insurance.md"The entire provisioning process takes about 15 minutes. When the TTL expires, the environment" — verdict: unverifiable; evidence: TTL Stacks are a real, documented Pulumi Deployments feature: "TTL (Time to Live) Stacks are temporary stacks that are automatically destroyed after a specified period of time." However, no independent public source confirms the specific "…; source: https://www.pulumi.com/docs/deployments/deployments/using/triggers/; intuition: A precise "about 15 minutes" figure for a specific customer's provisioning process is plausible but is an internal anec… (WebSearch dispatched but verification did not converge within the turn budget) — Author check: customer-reported ≈15-minute provisioning time; no public source. Confirm with Boost. Non-blocking.

  • [L98] content/case-studies/boost-insurance.md"30 minutes saved per developer per debugging session. Restoring a database in the cloud takes" — verdict: unverifiable; evidence: No public source corroborates or contradicts the specific "30 minutes saved per developer per debugging session" figure attributed to Boost Insurance's use of Pulumi; this appears to be a specific internal metric from the customer intervie…; source: WebSearch ran query "Boost Insurance Pulumi case study 30 minutes saved per developer"; top results didn't address the claim; intuition: Round, specific per-session time-savings figures in case studies are typically self-reported by the customer and not in… — Author check: the headline Results metric; customer-reported, no public source. Confirm with Boost and keep consistent with L29/L84-86. Non-blocking.

  • [L99] content/case-studies/boost-insurance.md"about 15 minutes, compared to 45 or more minutes for a remote developer to download and restore" — verdict: unverifiable; evidence: This appears to be a specific first-party detail from Pulumi's interview with Boost Insurance (about remote developer environment setup/restore times) that is not corroborated by any independent public source; web searches surfaced only un…; source: WebSearch ran query "Pulumi case study Boost Insurance 15 minutes developer download restore"; top results didn't address the claim — Author check: customer-reported restore-time comparison (≈15 min vs 45+ min); no public source. Confirm with Boost. Non-blocking.

  • [L127-131] content/case-studies/boost-insurance.md"Isolated environments on the Boost Insurance platform spin up in about 15 minutes and tear themselves down on schedule." — verdict: unverifiable; evidence: No public source (Pulumi case studies page, Caylent's Boost Insurance case study, or other search results) mentions a specific "15 minutes" spin-up time for isolated environments at Boost Insurance; the only related figures found describe…; source: WebSearch ran query "Pulumi case study Boost Insurance environments spin up tear down"; top results didn't address the specific 15-minute claim; intuition: Suspiciously precise number (15 minutes) with no corroborating source found; could be an LLM-fabricated specific detail… — Author check: the conclusion restates the ≈15-minute figure; customer-reported, no public source. Confirm with Boost and keep consistent with the earlier mentions. Non-blocking.

  • [L129] content/case-studies/boost-insurance.md"Boost's multi-project GCP environment using OIDC federation. Each GCP project has its own" — verdict: unverifiable; evidence: This describes Boost Insurance's own internal multi-project GCP architecture using OIDC federation — a customer-specific detail from a case study interview, not something confirmable against public Pulumi documentation or GitHub sources. G…; source: WebSearch ran query "Boost Insurance Pulumi case study multi-project GCP OIDC federation"; no source described Boost's specific architecture — Author check: description of Boost's own multi-project GCP / OIDC-federation architecture; a customer-specific detail, not verifiable against public docs. Confirm it matches Boost's setup. Non-blocking.

  • [L134] content/case-studies/boost-insurance.md"Pulumi Cloud ties it all together with centralized visibility into every" — verdict: unverifiable; evidence: verification did not converge within 8 turns — Author check: this restates a standard Pulumi Cloud capability (centralized visibility into stacks, resources, and update history) documented at /docs/pulumi-cloud/, which resolves. Automated verification ran out of time rather than finding a problem — low concern. Non-blocking.

@github-actions

Copy link
Copy Markdown
Contributor

💡 Pre-existing issues in touched files (optional)

No pre-existing issues in touched files.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

  • 2026-07-13T20:23:05Z — New Boost Insurance case study: mechanics clean (links, logo, anchors, frontmatter match sibling template); no blockers. 18 customer-reported figures flagged for author confirmation; one verbatim sentence repeated between exec summary and body opening. (bb99101)

Need a re-review? Want to dispute a finding? Mention @claude and include #update-review.
(For ad-hoc questions or fixes, just @claude — no hashtag.)

@github-actions github-actions Bot added review:no-blockers Claude review completed cleanly; outstanding is empty and removed review:in-progress Claude review is currently running labels Jul 13, 2026
@github-actions github-actions Bot added review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention and removed review:no-blockers Claude review completed cleanly; outstanding is empty labels Jul 14, 2026

@jkodroff jkodroff left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with comments.


## The business challenge {#the-challenge}

Boost Insurance operates in one of the most heavily regulated industries in the United States.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should technically be one line per paragraph for nice diffing purposes IMO, but it's a customer story and it doesn't matter that much.

allow_long_title: true
description: |
Boost Insurance built a self-service platform with Pulumi that provisions ephemeral, time-bound environments in the cloud, eliminating the risk of storing production data on developer machine.
meta_desc: Boost Insurance eliminated production data on developer laptops by building a self-service platform with Pulumi, reducing breach risk and saving developer time.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to use the phrases "regulatory compliance" (and also, if applicable - not sure - "data residency") as prominently as possible.

"Someone goes and steals a developer's laptop — we now have a reportable breach," said Richard Genthner, CISO at Boost Insurance. "We have to report not only to our partners, but to the state of New York, all 50 states, and the federal government. We have to notify every single person that's ever had a policy with us. It becomes a massive problem."

Boost has developers working remotely across multiple countries, and some partner contracts
explicitly require that data never leaves the United States. The existing tooling — StrongDM for

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may not want to call out StrongDM by name here since they are not a direct competitor of ours.

Comment on lines +102 to +103
The [Automation API](/docs/iac/concepts/automation-api/) is the foundation. Rather than shelling
out to `pulumi up`, Boost's Go application embeds Pulumi as a library, programmatically creating

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this is a customer story, we might want to make this a little less technical and talk more about what capabilities it enables, which is what we get at in the next sentence.

Comment on lines +111 to +112
and all of its resources, no cron jobs or manual cleanup required. This is what ensures that
isolated environments don't accumulate cost or become a security liability.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, suggest leading with the capabilities (cost, security) rather than the technical details.

Comment on lines +117 to +118
provisioning and destroying environments. This eliminates long-lived service account keys and
keeps the credential lifecycle fully automated.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And same here.

Comment on lines +120 to +121
[Pulumi Cloud](/docs/pulumi-cloud/) ties it all together with centralized visibility into every
active environment, with stacks, resources, and update history in one place. For a regulated insurance

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And again.


## Conclusion {#conclusion}

By building on Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC, Boost turned a serious

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By building on Pulumi's Automation API, Pulumi Deployments, and Pulumi ESC, Boost turned a serious
By building on Pulumi's infrastructure platform, Boost turned a serious

compliance liability into a self-service capability its developers actually enjoy using. Production
data stays inside Boost's controlled GCP infrastructure, isolated environments spin up in about 15
minutes and tear themselves down on schedule, and the audit trail regulators require is captured
automatically — all without a ticket queue for the platform team.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
automatically — all without a ticket queue for the platform team.
automatically — all without needing to file a request to the platform team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain:blog PR touches blog posts or customer stories review:stale New commits since last Claude review; refresh on next ready-transition or @claude mention

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants